Re: [ClusterLabs] [Announce] clufter v0.77.2 released

2019-08-15 Thread Jan Pokorný
On 14/08/19 16:26 +0200, Jan Pokorný wrote:
> I am happy to announce that clufter, a tool/library for transforming
> and analyzing cluster configuration formats, got its version 0.77.2
> tagged and released (incl. signature using my 60BCBB4F5CD7F9EF key):
> 
> 
> or alternative (original) location:
> 
> 
> 
> The updated test suite for this version is also provided:
> 
> or alternatively:
> 

Later on, I've found out that Fedora now mandates packagers to run
the OpenPGP signature verification as an initial step in the build
process whenever upstream publishes such signatures.  Preferably in
this scenario, upstream would also publish the key(s) as a publicly
available key ring (this is something immutable and easily shareable
in a truly distributed manner, also independent of a fragile
-- as we could learn recently -- key servers infrastructure).

In addition, I've realized that using my general signing key
associated with my work life identity (and used to sign this very
message, for instance) is not the best choice for any sort of
long-term contingency.

Therefore, I am now killing two birds with one stone with following:

1. I am hereby publishing such a keyring as:
   
   

   with following digests:
   SHA256 (clufter-2019-08-15-5CD7F9EF.keyring) = 
b2917412ed6d15206235ad98a14f4b51cbe15c66f534965bd31a13c01984305b
   SHA512 (clufter-2019-08-15-5CD7F9EF.keyring) = 
beedc493a04e3bd13c88792b0d9c0b9667a3a182416524c755ef1a2d60328c049d79a9ee88648eaf3f5965f8819221667fbb6d7fe2b5c92cd38b96226d44ea31

2. I am hereby and ahead-of-time detailing how the rollover be
   conducted should I decide to swap the signing key/related signing
   identity, barring a disaster (the purpose is to render any rough
   tampering attempts self-evident, since they would not follow the
   protocol set forth here):

   the first clufter release following such change will be signed
   with both the above specified key and the new/non-identical one
   (concatenated detached signatures in one file as usual) that
   will be present at distribution site/mirror likewise in a form
   "clufter--.keyring",
   where  is to correspond to the closest
   date prior to such release (in case there are more);
   once this "transaction is committed", default assumption for
   any subsequent one remains along the same lines, just with
   the newly established key as an origin

(Rationale for encoding the date hints in the file names: shall be
trivial to pick the correct keyring[s] related to the timestamp
of the the tarball -- or of the newest file within the tarball).

-- 
Jan (Poki)


pgpf4BgI3Mi3s.pgp
Description: PGP signature
___
Manage your subscription:
https://lists.clusterlabs.org/mailman/listinfo/users

ClusterLabs home: https://www.clusterlabs.org/

[ClusterLabs] [Announce] clufter v0.77.2 released

2019-08-14 Thread Jan Pokorný
I am happy to announce that clufter, a tool/library for transforming
and analyzing cluster configuration formats, got its version 0.77.2
tagged and released (incl. signature using my 60BCBB4F5CD7F9EF key):


or alternative (original) location:



The updated test suite for this version is also provided:

or alternatively:


I am not so happy that this is only limited to bare minimum to get
clufter working with upcoming Python 3.8 (appears rather aggressive
about compatibility, even if some of that are just enforcements of
previous deprecations) plus some small accrued changes over time,
but there was no room to deliver more since the last release.
Quite some catching up with the recent developments, as also asked on
this list[1], is pending, hopefully this will get rectified soon.

[1] https://lists.clusterlabs.org/pipermail/users/2019-July/026057.html


Changelog highlights for v0.77.2 (also available as a tag message):

- Python 3 (3.8 in particular) compatibility improving release

- enhancements:
  . knowledge about mapping various platforms to particular cluster
component sets got updated so as to target these more reliably
-- note however that current capacity for package maintenance
does not allow for adding support for new evolutions of such
components, even when they are nominally recognized like that
(mostly a concern regarding corosync3/kronosnet, and new and
backward incompatible changes in pcs)
  . specfile received more care regarding using precisely qualified
Python interpreters and process of Python byte-compilation was
taken fully under the explicit control of where familiarity
for that is established
- internal enhancements:
  . previously introduced text/data separation to align with Python 3
regression in the test suite was rectified
  . mutliple newly identified issues with Python 3.8 were fixed
(deprecated and dropped standard library objects swapped for
the straightforward replacements, newly imposed metaclass
and relative module import related constraints were reflected)
  . (automatically reported) resource (open file descriptor) leak
was resolved

* * *

The public repository (notably master and next branches) is currently at

(rather than ).

Official, signed releases can be found at
 or, alternatively, at

(also beware, automatic git archives preserve a "dev structure").

Natively packaged in Fedora (python3-clufter, clufter-cli, ...).

Issues & suggestions can be reported at either of (regardless if Fedora)
,
.


Happy clustering/high-availing :)

-- 
Jan (Poki)


pgpKgJJYweR5p.pgp
Description: PGP signature
___
Manage your subscription:
https://lists.clusterlabs.org/mailman/listinfo/users

ClusterLabs home: https://www.clusterlabs.org/