Re: Updated draft ballot
On Fri, Dec 06, 2019 at 07:54:59PM +0100, Kurt Roeckx wrote:
> On Thu, Dec 05, 2019 at 11:55:59PM +0100, Kurt Roeckx wrote:
> > Hi,
> >
> > Here is a new draft ballot:
>
> Here is a new one:
And even a newer one:
Voting period starts 2019-12-07 00:00:00 UTC
Votes must be received by 2019-12-27 23:59:59 UTC
The following ballot is for voting on init systems and systemd
This vote is being conducted as required by the Debian Constitution.
You may see the constitution at https://www.debian.org/devel/constitution.
For voting questions or problems contact secretary@debian.org.
The details of the general resolution can be found at:
https://www.debian.org/vote/2019/vote_002
Also, note that you can get a fresh ballot any time before the end of
the vote by sending a signed mail to
ballot@vote.debian.org
with the subject "gr_initsystems".
To vote you need to be a Debian Developer.
HOW TO VOTE
To cast a vote, it is necessary to send this ballot filled out to a
dedicated e-mail address, in a signed message, as described below.
The dedicated email address this ballot should be sent to is:
gr_initsystems@vote.debian.org
The form you need to fill out is contained below in this
message, marked with two lines containing the characters
'-=-=-=-=-=-'. Do not erase anything between those lines, and do not
change the choice names.
There are 8 choices in the form, which you may rank with numbers between
1 and 8. In the brackets next to your preferred choice, place a 1.
Place a 2 in the brackets next to your next choice. Continue until you
reach your last choice. Do not enter a number smaller than 1 or larger
than 8.
You may skip numbers, leave some choices unranked, and rank options
equally. Unranked choices are considered equally the least desired
choices, and ranked below all ranked choices.
To vote "no, no matter what", rank "Further Discussion" as more desirable
than the unacceptable choices, or you may rank the "Further Discussion"
choice and leave choices you consider unacceptable blank. (Note: if the
"Further Discussion" choice is unranked, then it is equal to all other
unranked choices, if any -- no special consideration is given to the
"Further Discussion" choice by the voting software).
Finally, mail the filled out ballot to: gr_initsystems@vote.debian.org.
Don't worry about spacing of the columns or any quote characters (">")
that your reply inserts.
NOTE: The vote must be GPG signed (or PGP signed) with your key that is
in the Debian keyring. You may, if you wish, choose to send a signed,
encrypted ballot: use the vote key appended below for encryption.
The voting software (Devotee) accepts mail that either contains only an
unmangled OpenPGP message (RFC 2440 compliant), or a PGP/MIME mail
(RFC 3156 compliant). To avoid problems I suggest you use PGP/MIME.
VOTING SECRECY
This is a non-secret vote. After the voting period is over the details on
who voted what will be published. During the vote itself the only
information that will be published is who voted.
You can encrypt your message to the voting system to keep your vote secret
until the end of the voting period. The software will also try to keep
your vote secret and will encrypt the reply it sends to you.
VOTING FORM
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
7b77e0f2-4ff9-4adb-85e4-af249191f27a
[ ] Choice 1: F: Focus on systemd
[ ] Choice 2: B: Systemd but we support exploring alternatives
[ ] Choice 3: A: Support for multiple init systems is Important
[ ] Choice 4: D: Support non-systemd systems, without blocking progress
[ ] Choice 5: H: Support portability, without blocking progress
[ ] Choice 6: E: Support for multiple init systems is Required
[ ] Choice 7: G: Support portability and multiple implementations
[ ] Choice 8: Further Discussion
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
----------------------------------------------------------------------
BALLOT OPTIONS
Choice 1: F: Focus on systemd
=============================
This resolution is a position statement under section 4.1 (5) of the Debian
constitution:
Cross-distribution standards and cooperation are important factors in the
choice of core Debian technologies. It is important to recognize that the
Linux ecosystem has widely adopted systemd and that the level of
integration of systemd technologies in Linux systems will increase with
time.
Debian is proud to support and integrate many different technologies. With
everything we do, the costs and benefits need to be considered, both for
users and in terms of the effects on our development community. An init
system is not an isolated component, but is deeply integrated in the core
layer of the system and affects many packages. We believe that the
benefits of supporting multiple init systems do not outweigh the costs.
Debian can continue to provide and explore other init systems, but systemd
is the only officially supported init system. Wishlist bug reports with
patches can be submitted, which package maintainers should review like
other bug reports with patches. As with systemd, work should be done
upstream and in cooperation with other Linux and FOSS distributions where
possible. The priority is on standardization without the reliance on
complicated compatibility layers.
Integrating systemd more deeply into Debian will lead to a more integrated
and tested system, improve standardization of Linux systems, and bring
many new technologies to our users. Packages can rely upon, and are
encouraged to make full use of, functionality provided by systemd.
Solutions based on systemd technologies will allow for more
cross-distribution cooperation. The project will work on proposals and
coordinate transitions from Debian-specific solutions where appropriate.
Choice 2: B: Systemd but we support exploring alternatives
==========================================================
Using its power under Constitution section 4.1 (5), the project issues the
following statement describing our current position on Init systems,
multiple init systems, and the use of systemd facilities. This statement
describes the position of the project at the time it is adopted. That
position may evolve as time passes without the need to resort to future
general resolutions. The GR process remains available if the project needs
a decision and cannot come to a consensus.
The Debian project recognizes that systemd service units are the preferred
configuration for describing how to start a daemon/service. However,
Debian remains an environment where developers and users can explore and
develop alternate init systems and alternatives to systemd features. Those
interested in exploring such alternatives need to provide the necessary
development and packaging resources to do that work. Technologies such as
elogind that facilitate exploring alternatives while running software that
depends on some systemd interfaces remain important to Debian. It is
important that the project support the efforts of developers working on
such technologies where there is overlap between these technologies and
the rest of the project, for example by reviewing patches and
participating in discussions in a timely manner.
Packages should include service units or init scripts to start daemons
and services. Packages may use any systemd facility at the package
maintainer's discretion, provided that this is consistent with other
Policy requirements and the normal expectation that packages shouldn't
depend on experimental or unsupported (in Debian) features of other
packages. Packages may include support for alternate init systems besides
systemd and may include alternatives for any systemd-specific interfaces
they use. Maintainers use their normal procedures for deciding which
patches to include.
Debian is committed to working with derivatives that make different
choices about init systems. As with all our interactions with downstreams,
the relevant maintainers will work with the downstreams to figure out
which changes it makes sense to fold into Debian and which changes remain
purely in the derivative.
Choice 3: A: Support for multiple init systems is Important
===========================================================
The project issues the following statement describing our current position
on Init systems, multiple init systems, and the use of systemd facilities.
This statement describes the position of the project at the time it is
adopted. That position may evolve as time passes without the need to
resort to future general resolutions. The GR process remains available if
the project needs a decision and cannot come to a consensus.
Being able to run Debian systems with init systems other than systemd
continues to be something that the project values. Every package should
work with pid1 != systemd, unless it was designed by upstream to work
exclusively with systemd and no support for running without systemd is
available. It is an important bug (although not a serious one) when
packages should work without systemd but they do not. According to the NMU
guidelines, developers may perform non-maintainer uploads to fix these
bugs.
Software is not to be considered to be designed by upstream to work
exclusively with systemd merely because upstream does not provide, and/or
will not accept, an init script.
Modification of Policy to adopt systemd facilities instead of existing
approaches is discouraged unless an equivalent implementation of that
facility is available for other init systems.
Choice 4: D: Support non-systemd systems, without blocking progress
===================================================================
PRINCIPLES
1. We wish to continue to support multiple init systems for the
foreseeable future. And we want to improve our systemd support.
2. It is primarily for the communities in each software ecosystem to
maintain and develop their respective software - but with the active
support of other maintainers and gatekeepers where needed.
SYSTEMD DEPENDENCIES
3. Ideally, packages should be fully functional with all init systems.
This means (for example) that daemons should ship traditional init
scripts, or use other mechanisms to ensure that they are started without
systemd. It also means that desktop software should be installable, and
ideally fully functional, without systemd.
4. So failing to support non-systemd systems, where no such support is
available, is a bug. But it is not a release-critical bug. Whether the
requirement for systemd is recorded as a formal bug in the Debian bug
system, when no patches are available, is up to the maintainer.
5. When a package has reduced functionality without systemd, this should
not generally be documented as a (direct or indirect) Depends or
Recommends on systemd-sysv. This is because with such dependencies,
installing such a package can attempt to switch the init system, which is
not what the user wanted. For example, a daemon with only a systemd unit
file script should still be installable on a non-systemd system, since it
could be started manually.
One consequence of this is that on non-systemd systems it may be possible
to install software which will not work, or not work properly, because of
an undeclared dependency on systemd. This is unfortunate but trying to
switch the user's init system is worse. We hope that better technical
approaches can be developed to address this.
6. We recognise that some maintainers find init scripts a burden and we
hope that the community is able to find ways to make it easier to add
support for non-default init systems. Discussions about the design of such
systems should be friendly and cooperative, and if suitable arrangements
are developed they should be supported in the usual ways within Debian.
CONTRIBUTIONS OF NON-SYSTEMD SUPPORT WILL BE ACCEPTED
7. Failing to support non-systemd systems when such support is available,
or offered in the form of patches (or packages), should be treated as a
release critical bug. For example: init scripts must not be deleted merely
because a systemd unit is provided instead; patches which contribute
support for other init systems (with no substantial effect on systemd
installations) should be filed as bugs with severity “serious”.
This is intended to provide a lightweight but effective path to ensuring
that reasonable support can be provided to Debian users, even where the
maintainer's priorities lie elsewhere. (Invoking the Technical Committee
about individual patches is not sensible.)
If the patches are themselves RC-buggy (in the opinion of, initially, the
maintainer, and ultimately the Release Team) then of course the bug report
should be downgraded or closed.
8. Maintainers of systemd components, or other gatekeepers (including
other maintainers and the release team) sometimes have to evaluate
technical contributions intended to support non-systemd users. The
acceptability to users of non-default init systems, of quality risks of
such contributions, is a matter for the maintainers of non-default init
systems and the surrounding community. But such contributions should not
impose nontrivial risks on users of the default configuration (systemd
with Recommends installed).
NON-INIT-RELATED DECLARATIVE SYSTEMD FACILITIES
9. systemd provides a variety of facilities besides daemon startup. For
example, creating system users or temporary directories. Current Debian
approaches are often based on debhelper scripts.
In general more declarative approaches are better. Where
* systemd provides such facility
* a specification of the facility (or suitable subset) exists
* the facility is better than the other approaches available in
* Debian, for example by being more declarative
* it is reasonable to expect developers of non-systemd systems
* including non-Linux systems to implement it
* including consideration of the amount of work involved
the facility should be documented in Debian Policy (by textual
incorporation, not by reference to an external document). The transition
should be smooth for all users. The non-systemd community should be given
at least 6 months, preferably at least 12 months, to develop their
implementation. (The same goes for any future enhancements.)
If policy consensus cannot be reached on such a facility, the Technical
Committee should decide based on the project's wishes as expressed in this
GR.
BEING EXCELLENT TO EACH OTHER
10. In general, maintainers of competing software, including maintainers
of the various competing init systems, should be accommodating to each
others' needs. This includes the needs and convenience of users of
reasonable non-default configurations.
11. Negative general comments about software and their communities,
including both about systemd itself and about non-systemd init systems,
are strongly discouraged. Neither messages expressing general dislike of
systemd, nor predictions of the demise of non-systemd systems, are
appropriate for Debian communication fora; likewise references to bugs
which are not relevant to the topic at hand.
Communications on Debian fora on these matters should all be encouraging
and pleasant, even when discussing technical problems. We ask that
communication fora owners strictly enforce this.
12. We respectfully ask all Debian contributors including maintainers,
Policy Editors, the Release Team, the Technical Committee, and the Project
Leader, to pursue these goals and principles in their work, and embed them
into documents etc. as appropriate.
(This resolution is a position statement under s4.1(5).)
Choice 5: H: Support portability, without blocking progress
===========================================================
PRINCIPLES
1. The Debian project reaffirms its commitment to be the glue that binds
and integrates different software that provides similar or equivalent
functionality, with their various users, be them humans or other software,
which is one of the core defining traits of a distribution.
2. We consider portability to different hardware platforms and software
stacks an important aspect of the work we do as a distribution, which
makes software architecturally better, more robust and more future-proof.
3. We acknowledge that different upstream projects have different views on
software development, use cases, portability and technology in general.
And that users of these projects weight tradeoffs differently, and have at
the same time different and valid requirements and/or needs fulfilled by
these diverse views.
4. Following our historic tradition, we will welcome the integration of
these diverse technologies which might sometimes have conflicting
world-views, to allow them to coexist in harmony within our distribution,
by reconciling these conflicts via technical means, as long as there are
people willing to put in the effort.
5. This enables us to keep serving a wide range of usages of our
distribution (some of which might be even unforeseen by us). From servers,
to desktops or deeply embedded; from general purpose to very specifically
tailored usages. Be those projects hardware related or software based,
libraries, daemons, entire desktop environments, or other parts of the
software stack.
SYSTEMD DEPENDENCIES
6. Ideally, packages should be fully functional with all init systems.
This means (for example) that daemons should ship traditional init
scripts, or use other mechanisms to ensure that they are started without
systemd. It also means that desktop software should be installable, and
ideally fully functional, without systemd.
7. So failing to support non-systemd systems, where no such support is
available, is a bug. But it is not a release-critical bug. Whether the
requirement for systemd is recorded as a formal bug in the Debian bug
system, when no patches are available, is up to the maintainer.
8. When a package has reduced functionality without systemd, this should
not generally be documented as a (direct or indirect) Depends or
Recommends on systemd-sysv. This is because with such dependencies,
installing such a package can attempt to switch the init system, which is
not what the user wanted. For example, a daemon with only a systemd unit
file script should still be installable on a non-systemd system, since it
could be started manually.
One consequence of this is that on non-systemd systems it may be possible
to install software which will not work, or not work properly, because of
an undeclared dependency on systemd. This is unfortunate but trying to
switch the user's init system is worse. We hope that better technical
approaches can be developed to address this.
9. We recognise that some maintainers find init scripts a burden and we
hope that the community is able to find ways to make it easier to add
support for non-default init systems. Discussions about the design of such
systems should be friendly and cooperative, and if suitable arrangements
are developed they should be supported in the usual ways within Debian.
CONTRIBUTIONS OF NON-SYSTEMD SUPPORT WILL BE ACCEPTED
10. Failing to support non-systemd systems when such support is available,
or offered in the form of patches (or packages), should be treated as a
release critical bug. For example: init scripts must not be deleted merely
because a systemd unit is provided instead; patches which contribute
support for other init systems (with no substantial effect on systemd
installations) should be filed as bugs with severity “serious”.
This is intended to provide a lightweight but effective path to ensuring
that reasonable support can be provided to Debian users, even where the
maintainer's priorities lie elsewhere. (Invoking the Technical Committee
about individual patches is not sensible.)
If the patches are themselves RC-buggy (in the opinion of, initially, the
maintainer, and ultimately the Release Team) then of course the bug report
should be downgraded or closed.
11. Maintainers of systemd components, or other gatekeepers (including
other maintainers and the release team) sometimes have to evaluate
technical contributions intended to support non-systemd users. The
acceptability to users of non-default init systems, of quality risks of
such contributions, is a matter for the maintainers of non-default init
systems and the surrounding community. But such contributions should not
impose nontrivial risks on users of the default configuration (systemd
with Recommends installed).
NON-INIT-RELATED DECLARATIVE SYSTEMD FACILITIES
12. systemd provides a variety of facilities besides daemon startup. For
example, creating system users or temporary directories. Current Debian
approaches are often based on debhelper scripts.
In general more declarative approaches are better. Where
* systemd provides such facility
* a specification of the facility (or suitable subset) exists
* the facility is better than the other approaches available in
* Debian, for example by being more declarative
* it is reasonable to expect developers of non-systemd systems
* including non-Linux systems to implement it
* including consideration of the amount of work involved
the facility should be documented in Debian Policy (by textual
incorporation, not by reference to an external document). The transition
should be smooth for all users. The non-systemd community should be given
at least 6 months, preferably at least 12 months, to develop their
implementation. (The same goes for any future enhancements.)
If policy consensus cannot be reached on such a facility, the Technical
Committee should decide based on the project's wishes as expressed in this
GR.
BEING EXCELLENT TO EACH OTHER
13. In general, maintainers of competing software, including maintainers
of the various competing init systems, should be accommodating to each
others' needs. This includes the needs and convenience of users of
reasonable non-default configurations.
14. Negative general comments about software and their communities,
including both about systemd itself and about non-systemd init systems,
are strongly discouraged. Neither messages expressing general dislike of
systemd, nor predictions of the demise of non-systemd systems, are
appropriate for Debian communication fora; likewise references to bugs
which are not relevant to the topic at hand.
Communications on Debian fora on these matters should all be encouraging
and pleasant, even when discussing technical problems. We ask that
communication fora owners strictly enforce this.
15. We respectfully ask all Debian contributors including maintainers,
Policy Editors, the Release Team, the Technical Committee, and the Project
Leader, to pursue these goals and principles in their work, and embed them
into documents etc. as appropriate.
(This resolution is a position statement under s4.1(5).)
Choice 6: E: Support for multiple init systems is Required
==========================================================
Being able to run Debian systems with init systems other than systemd
continues to be of value to the project. Every package MUST work with pid1
!= systemd, unless it was designed by upstream to work exclusively with
systemd and no support for running without systemd is available.
Software is not to be considered to be designed by upstream to work
exclusively with systemd merely because upstream does not provide, and/or
will not accept, an init script.
Choice 7: G: Support portability and multiple implementations
=============================================================
Principles
The Debian project reaffirms its commitment to be the glue that binds and
integrates different software that provides similar or equivalent
functionality, with their various users, be them humans or other software,
which is one of the core defining traits of a distribution.
We consider portability to different hardware platforms and software
stacks an important aspect of the work we do as a distribution, which
makes software architecturally better, more robust and more future-proof.
We acknowledge that different upstream projects have different views on
software development, use cases, portability and technology in general.
And that users of these projects weight trade-offs differently, and have
at the same time different and valid requirements and/or needs fulfilled
by these diverse views.
Following our historic tradition, we will welcome the integration of these
diverse technologies which might sometimes have conflicting world-views,
to allow them to coexist in harmony within our distribution, by
reconciling these conflicts via technical means, as long as there are
people willing to put in the effort.
This enables us to keep serving a wide range of usages of our distribution
(some of which might be even unforeseen by us). From servers, to desktops
or deeply embedded; from general purpose to very specifically tailored
usages. Be those projects hardware related or software based, libraries,
daemons, entire desktop environments, or other parts of the software
stack.
Guidance
In the same way Debian maintainers are somewhat constrained by the
decisions and direction emerging from their respective upstreams, the
Debian distribution is also somewhat constrained by its volunteer based
nature, which has as another of its core defining traits, not willing to
impose work obligations to its members, while at the same time being
limited by its members bounded interests, motivation, energy and time.
Because of these previous constraints, trying to provide guidance in a
very detailed way to apply the aforementioned principles, is never going
to be satisfactory, as it will end up being inexorably a rigid and
non-exhaustive list of directives that cannot possibly ever cover most
scenarios, which can perpetuate possible current tensions.
These will always keep involving case by case trade-offs between what
changes or requests upstreams might or might not accept, or the upkeep on
the imposed deltas or implementations the Debian members might need to
carry on. Which can never be quantified and listed in a generic and
universal way.
We will also keep in mind that what might be considered important for
someone, might at the same time be considered niche or an uninteresting
diversion of time for someone else, but that we might end up being on
either side of the fence when sending or receiving these requests.
We will be guided, as we have been in many other Debian contexts in the
past, by taking all the above into account, and discussing and evaluating
each situation, and respecting and valuing that we all have different
interests and motivations. That is in our general interest to try to work
things out with others, to compromise, to reach solutions or find
alternatives that might be satisfactory enough for the various parties
involved, to create an environment where we will collectively try to
reciprocate. And in the end and in most cases it's perhaps a matter of
just being willing to try.
Choice 8: Further Discussion
============================
This is the default option. Rank this option higher than the unacceptable
choices.
VOTE RESULTS
The responses to a valid vote shall be signed by the vote key created
for this vote. The public key for the vote, signed by the Project
secretary, is appended below.
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQENBF3qoxsBCADeYpsXgwgUrooFZpBPHdJWy3Ra6LnVlh8GzhZw/GIz2r3uooI2
VPf1wlU5HoxxdvMqAKig1rvdMblSXIBGX1liv2C9WrEIlIgRh5TYTnAeZkZmtj32
mjV2u+G8V4w+YPBCRJyMqw1CfAI45qcnFGG6/51WD6lGTTXfyXsmJJobAlqz/Y80
S0BHD6qYnWtGThd53Lj+K4lD0NiWa4FcWtXR1CVoiCU4IIxXD5jnAuPcQBdW2cdW
aSDaX8srURyNFqwoeqDGhpHpXSoEt7cuW+gU8wv5LvfNNdgvkHHQ+ssd4SWHnvcg
jzf0CEK8Z/6Mkd4zYT+7T/WYZrjcynHw5mSLABEBAAG0MEdSIEluaXQgc3lzdGVt
cyA8Z3JfaW5pdHN5c3RlbXNAdm90ZS5kZWJpYW4ub3JnPokBPgQTAQgAKAUCXeqj
GwIbAwUJACeNAAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQyRsyW3fyUvt9
4gf/ZYHCgiZK2QmhujyOF851O9cAdqg0BLzD5p4eGwtzUyy9jpE+9QKd2F6jR5eq
tJXBLkWD+AEnWtcyh5f7WKNe4Mjsl4FlUTQEvPutnj272Kw1j1AbcrXD+EvG0gqL
pCijd4P5k0IALHCbQjsp+MsZOQ6zRrIRNSZoCAW1udCLSyxaw8UitaUQZksG3DYk
wukWZI38lXn+OjvoM5NLME8/VCKNwQ76mTJfaNuP2RZrALjUU5B0rLy6z6DS7lIm
RYMDO3GqGnf/EZXQmS/HKidPhrsH+Em55s2hC+1vc9byetV/ssF/zKgsGIA5c5HY
fLOE0isiuqvF1CVTwgRRCI0+CIkCMwQQAQoAHRYhBOXlJWDdkcVW3b2l0CBkxTZB
wl5dBQJd6qNuAAoJECBkxTZBwl5dilUP/3XI/PDmRibrhdIktwHgGpmsFYVE22k1
g6vYkrkRa6hiwVl/YOugNHOW2ExbhaaYZFx2ftQi7d+yxJvr2kj5/v1rNXlHo99j
cCPUqGhXh+ljBpGXeYkzJ4a42jJVSvykanPHcVcVruR+PF1icVSecO0J7QuUfINF
xRTS+Hzr3B1hBiy8jzoGtWTWrbDtZMAVBynakGhqLEezay/qLE3gajcXrvi4Z6Aj
QnEpiVtLmueOOiQZ/XwkM+l1VMlCe9T8WdJSR4ab3XXZ6t2X7cgSPHDPMVjp5NbW
oDf7NY8I3/Jdy8//qVqFdDuZKqmdzhgK1yTeYkbr2RV0Bjp5iMMyXK3PJFPGIwEg
bkiTIr2bnyqLtOazstJ34ZJcwSPwKDpHKw3TaaHF3J00xpoxR+qXUdq7ardd3PW0
H67O/rqwTwX9agCpIAXHnbAhG79jYjZPskEgkTfKaCm8gIcoQCTX0J9msFP4RUQh
3pOGIBm0XtzlVDv+HAjqdahZVQoh+5+uNoS3GAf7saW4bCYDY/F87KEwTjvZczry
QGUO0dKTxapLmYomSY5RNXVs5jNXqG+N3Cm0atMhyz9hFBysz2YUI2Zyn7PWYZVa
7airYRIaNr2+lJDrS//jlsAy48jhGsnwCWeW+5mcylVdr9gUCiyZP+K61TbLZi0r
rPIsljf31vr/uQENBF3qoxsBCAC/a1Tcf2vqAi/bAjX/2mb+MmcqQrrTTFpgcCJ+
4VAoEOQ06gDLL7dJBrAN3lB5cTOlOsV2y0gS58NgOfEaIMyH8diWgdWus5m2OgZT
C4DhQGvfR8p15+e270pPvWi0CXHOMzJdCvuUDSbZVaMfxowzA629FQ3FNqszewmL
d3Z2VaLI3/wLB0BoPPgLPanN/HXJH7rTR0CK00YWPKKyTFJ8vUzwZJ85RtKPqXmX
zNzAOKRYI+NzcSs58j3HH4An7tTBd9fBWGc3OlXPZGUxUfv9B8QZG6KSZZgThcz6
EZE6EawTsCDFCl/NQP5ZqNlwukw7m9EO0nfAyLZfCbjqdqApABEBAAGJASUEGAEI
AA8FAl3qoxsCGwwFCQAnjQAACgkQyRsyW3fyUvuQrwf/YV8Fp5fH7ScdIxFeYolo
6VtDSu0nhDWVaaohGkMm9D4AhgeeQ3PW0P1Kz3fabtDJ3qrOOL1QVzM65o2djHnK
Fs8iUPT5kpIR7ddDYjHi4gjbd892lD3lpzhlIMhhAAm9+Etjg96fU5msBDdssBtJ
sF+OlgaW759E5nbowJt+mFStPzLnBUBQ49/4B2jHljHgEm/quQJ/wpSkuLqRIV5/
gt8YcwFFsq+KH/XmO2QyaMI+2Hfzu1FJkPh1hiKvKd85N0+bloLT8zcd4dRiLAab
9/0ay/Nu+Mgt1MDmzKXhX5rxXZ90B9TtZzbIjcsgIWJL/qDk84wakm8MHHuFvcG7
qw==
=U0yp
-----END PGP PUBLIC KEY BLOCK-----
Reply to: