• General Resolution: Init systems and systemd: Second call for votes

    From Debian Project Secretary - Kurt Roe@21:1/5 to All on Sat Dec 14 14:20:01 2019
    Hi,

    This is the second call for votes for the General Resolution about
    init systems and systemd.

    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-----


    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEUWHm1ANgDdycoJP748TdzR5MEkQFAl3038cACgkQ48TdzR5M EkRn6g/+OWYBqEo3X53TLU4b4ueHoHqrwhWhVNuFXGzx1qpO5HkHQvdMxqCfebHK HjNAQRlPYYkf/pvttzVqY25mBBTSoOlGdp4wfqBgPtXB9wsrURTbs/ATj9TnxXeN X7lfScBjgTR8tWh0ve06LFHZqgwZIebXb8/sDLFGdtImUGaxTXoh8cUlAsdxVVa1 52CyuDaW/8DoqzYrso44eslZtadZ/y3rnYHyWJAShItsKwpTa3ql4zoXoDaJfG1O Xfsda3ppPygdIdAxhTqmWuJ34RrUoYA/E93n+TXOFPmR5Upsw5Z/n2OidmewVcft Ca7fsvSHCiB/gESl6tc/OUffjwx6BewuPzGh3mCzh/FLGHd/bp0jkohE8fH94vWC Fk2OlLFHSL2GspQVDNSRVs7w0Th7L4xoq4MssuMWUo3BqSOg/bR6IEjpTc/e1r3s 4eW1ciJaMo+j/WONb7MCu2y16y+x9S+qys2yhnFW5W+UKvizOMXlgsSCa/c5vLua TMMAMooBt/XAZLZPqUff07fPNv8yioMkjBuyh+oh4hooiwkejVt9x2kSyGfz7fsT bOP1A99l4s9qMn/RITpGubVr2GX4fpV42x4wEhzM5dl/t269gzwbb8vGdqozTUU3 s/O4FxyYd+Y9tOxSlIdEi/GN98fRw8SRXkhyIfsrCScGE4H5pG8=
    =+pI7
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)