• [backintime] Switch the maintainer to "Debian Python Team (DPT)"

    From c.buhtz@posteo.jp@21:1/5 to All on Mon Jun 12 10:00:01 2023
    Dear Python Team,
    dear Jonathan,

    first of all, please take my congratulations for the Debian 12 release yesterday.

    I'm member of the upstream maintenance team of "Back In Time" [1].
    In short: I would like to switch its Debian Maintainer to "Debian Python
    Team (DPT)".

    I'm a little concerned that the way I'm addressing this is perceived as
    rude. I'm not that familiar with how things work here yet.
    I tried to contact some persons in private before this.

    Currently Jonathan Wiltshire is official DM for that package.
    I'm sure he makes a good job as DM. But other packages might have higher priorities. He do not response in time and in some topics never. As
    upstream maintainer I miss the dialog with "my distro maintainer". Also
    there was a RFS [2] without concrete response/decision. It wasn't clear
    to me if it wasn't uploaded because of the Freeze or just because no one
    was there to do it.

    In the last weeks before the Debian release there where other people
    around supporting me.
    Fabio Fantoni, Fabian Wolff and Sven Geuner for example.

    On the site of the Team is there a possibility to take over as DM for
    the package?
    Is there a defined process how this should be done?

    Thanks in advance.
    Christian Buhtz

    [1] -- <https://tracker.debian.org/pkg/backintime>
    [2] -- <https://bugs.debian.org/1033829>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jonathan Carter@21:1/5 to c.buhtz@posteo.jp on Mon Jun 12 10:50:02 2023
    Hi

    On 2023/06/12 09:51, c.buhtz@posteo.jp wrote:
    Currently Jonathan Wiltshire is official DM for that package.
    I'm sure he makes a good job as DM. But other packages might have higher priorities. He do not response in time and in some topics never. As
    upstream maintainer I miss the dialog with "my distro maintainer". Also
    there was a RFS [2] without concrete response/decision. It wasn't clear
    to me if it wasn't uploaded because of the Freeze or just because no one
    was there to do it.

    (just for the avoidance of confusion, I'm an entirely different Jonathan)

    You're very likely correct that the freeze impacted the upload. To
    upload newer versions of software (even for bug fixes) so late in the
    freeze, you have to write a proper justification to the release team and convince them that the benefit of the upload outweighs the risk, so in
    the last few weeks of the freeze, very few packages get updated.

    Adding DPT to at least uploaders and having the package VCS in the
    python-team namespace would probably be a good idea, but that's up to
    Jonathan Wiltshire.

    -Jonathan

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From c.buhtz@posteo.jp@21:1/5 to jcc@debian.org on Sun Jul 23 09:10:01 2023
    Hello,

    On 2023-06-12 10:40 Jonathan Carter <jcc@debian.org> wrote:
    Adding DPT to at least uploaders and having the package VCS in the python-team namespace would probably be a good idea, but that's up to Jonathan Wiltshire.

    I have to state that after 5 weeks of waiting there is no reaction from Jonathan Wiltshire by mail, any bug-ticket (in context of backintime)
    and even IRC.

    There is also this bug ticket where I had specific questions (in August
    last year) only the maintainer can answer but got no reaction. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940319

    How can we proceed further?
    IMHO it is blocking the process waiting on someone who do not answer.

    Kind
    Christian Buhtz

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Carsten Schoenert@21:1/5 to All on Sun Jul 23 09:50:02 2023
    Hello Christian,

    Am 23.07.23 um 09:09 schrieb c.buhtz@posteo.jp:
    Hello,

    On 2023-06-12 10:40 Jonathan Carter <jcc@debian.org> wrote:
    Adding DPT to at least uploaders and having the package VCS in the
    python-team namespace would probably be a good idea, but that's up to
    Jonathan Wiltshire.

    I have to state that after 5 weeks of waiting there is no reaction from Jonathan Wiltshire by mail, any bug-ticket (in context of backintime)
    and even IRC.

    it might be sounds strange to you, but 5 or sometimes also 8 weeks and
    longer isn't a long time within Debian. I know that my answer isn't
    helping you, it's simply quite all of the DMs and DDs are doing their
    work for Debian within their free and spare time and they can decide
    when to work on something.
    And Jonathan isn't only active as package maintainer, it's up to him
    what are his priorities and on what he wanted to work on.

    There is also this bug ticket where I had specific questions (in August
    last year) only the maintainer can answer but got no reaction. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940319

    Why can't only the maintainer answer this?
    Also the issue is marked correctly as wishlist, typically this indicates
    also that the underlying issue isn't time critical.

    If you want to get applied something quickly then make it easy to the maintainer to accept the suggested modifications. Means prepare one (or
    more) patches which are easy and save to pick. I can't see anything like
    this within the bug report.

    For sure testing and test suites are always a good thing to add, but
    basically they are not needed for the functionality of a package.

    How can we proceed further?
    IMHO it is blocking the process waiting on someone who do not answer.

    I don't understand what or who is blocking whom here?
    Is it that you feel you are blocked with your upstream work by the
    maintainer?
    Do you like to have more power within the Debian package of your
    upstream work?
    Is there a issue in the Debian package that is causing trouble on the users?

    If you only think that the maintainer of backintime should be switched
    to the DPT then this is only a wish. And I don't think doing such a
    switch is improving the situation for you, still someone needs to do the
    work you requesting.
    The Debian policy is quite clear that a maintainer of a package has more
    or less the full power of the package, that's how Debian is build and
    also working for years.

    So far I've not seen any DPT member in the past weeks who would be
    willing to do work on the package backintime. If you want to improve
    this then you are welcome to become a member of the DPT by doing work on packages which are in the maintenance of the DPT, but becoming a DM will
    take time and requires to learn and accept the rules of being a DM.

    So you want to process further something?
    Provide patches, improve packages, enhance documentation, do some kind
    of the work. That's the typical answers to that question.

    --
    Regards
    Carsten

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From c.buhtz@posteo.jp@21:1/5 to c.schoenert@t-online.de on Thu Jul 27 22:00:01 2023
    Dear Carsten,

    thanks for your feedback, your kind words and your patience with my frustration. :)

    I was thinking about what it is what bothers me here. It is not that
    "the work" isn't done or bugs not fixed. It is that there is no
    reaction; zero; total silence.

    The current Debian release is fresh. All of you maintainers have done a
    lot of extra work in the last weeks to get it done. The next release is
    two years in the future. Totally understandable if someone now would
    take half or one year off from the maintainers job.

    But this needs to be communicated somehow. A simple mail with "I'm on
    holiday for the next 6 months" would be OK for me.

    But without any reaction it feels to me that the package is not
    important to the maintainer.

    This is not about a simple bug ticket. I asked seriously in public on
    the list if the DPT could take over the package. Especially in this
    situation I would expect a reaction. Asking in public is quit
    impolite by me. But before I've done this I tried to reach jmw several
    times.

    On 2023-07-23 09:45 Carsten Schoenert
    <c.schoenert@t-online.de> wrote:
    their work for Debian within their free and spare time and they can
    decide when to work on something.

    It is the same on my upstream site. No one gets and wants applause. We
    do this for our own.

    There is also this bug ticket where I had specific questions (in
    August last year) only the maintainer can answer but got no
    reaction. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940319

    Why can't only the maintainer answer this?

    You might haven't read all ticket comments or I wasn't able to make my
    question clear. The intention of my last comments to that ticket are to understand how Jonathan worked around the problem while packaging. It
    is my learning on the way becoming a Debian packager myself.

    As he describes the problem and I as understand, it must be impossible
    to build and package backintime for Debian. But as it is obvious it is
    somehow possible and I want to know how. I want to learn something
    specific about that packaging here.

    I don't understand what or who is blocking whom here?
    Is it that you feel you are blocked with your upstream work by the maintainer?
    [..]
    If you only think that the maintainer of backintime should be
    switched to the DPT then this is only a wish. And I don't think doing
    such a switch is improving the situation for you, still someone needs
    to do the work you requesting.

    All this is not about work in the meaning of fixing, uploading or
    something else. It is just about having a dialog. Without dialog I'm
    not able to learn and to take over packaging someday to save your
    resources. Not sure if it is against the Debian rules that upstream do
    its own Debian packaging.

    Participating to Debian sometimes feels like talking to a wall. I want
    to learn and improve my skills to someday jump into the Debian
    packaging wheel. From my experience with this list it seems easier to
    have dialog with the DPT.

    this then you are welcome to become a member of the DPT by doing work
    on packages which are in the maintenance of the DPT

    Exactly! That is why I want my package being switch from jmw to the DPT
    to make it "in the maintenance of the DPT".

    So you want to process further something?
    Provide patches, improve packages, enhance documentation, do some
    kind of the work. That's the typical answers to that question.

    I hope I made my point clear now that I want and still do this. E.g. I
    checked all debian bug tickets for backintime. But I'm not able doing
    this further when there is no dialog.

    it might be sounds strange to you, but 5 or sometimes also 8 weeks
    and longer isn't a long time within Debian.

    I know this and I'm not that new to Debian. :)
    Waiting weeks and months for a reaction (not work) is IMHO not OK.

    Kind
    Christian

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From c.buhtz@posteo.jp@21:1/5 to All on Fri Jul 28 09:20:01 2023
    Dear Mechtilde,

    thanks for taking time to reply.

    Am 28.07.2023 07:31 schrieb Mechtilde:
    Did you try to build the last released version?
    What are your problems to build backintime?

    At upstream I have no problems to build and test it because I'm
    upstream. ;)

    But in my understanding the problem described in the bug ticket is about building the package in Debian's build environment (servers?) where I
    have no idea about. Some of the checking tools (lintian?) might have a
    problem because my unit tests do write to home filesystem which is not
    allowed or possible in Debian's build environment. That is how I
    understand the ticket.

    At https://tracker.debian.org/pkg/backintime I can't find the right log
    or info describing the problem in detail. I'm not familiar with the
    system. That is why I ask questions like this because it is an
    opportunity to improve my understanding of Debian's build environment
    and learn more about all the fancy build-info (DD, UD, lintian, xyz,
    ...) links available.

    May I open a separate thread about the problem described in the ticket?

    Kind
    Christian

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Carsten Schoenert@21:1/5 to All on Fri Jul 28 12:00:01 2023
    Hello Christian,

    Am 27.07.23 um 21:56 schrieb c.buhtz@posteo.jp:
    Dear Carsten,

    thanks for your feedback, your kind words and your patience with my frustration. :)

    I was thinking about what it is what bothers me here. It is not that
    "the work" isn't done or bugs not fixed. It is that there is no
    reaction; zero; total silence.

    you really should read the Social Contract/DFSG, the Debian policy and
    the Developers reference a few times.

    https://www.debian.org/social_contract https://www.debian.org/doc/debian-policy/ https://www.debian.org/doc/manuals/developers-reference/

    There is no rule that any DD or DM *must* do something in Debian, so you probably have the wrong expectations.

    The current Debian release is fresh. All of you maintainers have done a
    lot of extra work in the last weeks to get it done. The next release is
    two years in the future. Totally understandable if someone now would
    take half or one year off from the maintainers job.

    But this needs to be communicated somehow. A simple mail with "I'm on
    holiday for the next 6 months" would be OK for me.

    There is a private list there such information *can* be given, again,
    there is no rule that I need to do this.
    There are options if some other DD believes a package is needing an
    update, that process is called NMU (non maintainer upload). Or if you
    think the other maintainer isn't doing his work in a time able manner, a
    DD can salvage a package.
    But these options are only doable by DDs! And that for a reason.

    But without any reaction it feels to me that the package is not
    important to the maintainer.

    This depends heavily from the POV. As written, taking a 6 month off time
    might be an important time span for you, but this isn't true for other
    people.

    This is not about a simple bug ticket. I asked seriously in public on
    the list if the DPT could take over the package. Especially in this
    situation I would expect a reaction. Asking in public is quit
    impolite by me. But before I've done this I tried to reach jmw several
    times.

    Debian isn't working that way! It's all a project of volunteers, that
    why I'm did chose to be part of it. We are not bound to a company and we
    wont this to happen. So we all have no obligation to do something in a
    specific time window.
    If you expect this than you should move to Canonical/Ubuntu, thats there businesses is made off.

    ...
    Why can't only the maintainer answer this?

    You might haven't read all ticket comments or I wasn't able to make my question clear. The intention of my last comments to that ticket are to understand how Jonathan worked around the problem while packaging. It
    is my learning on the way becoming a Debian packager myself.

    The "workaround", if there is one, is visible within the Debian package
    source.

    https://salsa.debian.org/jmw/pkg-backintime/-/commits/debian

    I don't see any workaround and there is non needed. The bug issue is
    about the not usable upstream test suite that would need to be called
    through d/rules.

    As he describes the problem and I as understand, it must be impossible
    to build and package backintime for Debian. But as it is obvious it is somehow possible and I want to know how. I want to learn something
    specific about that packaging here.

    To quote from the BTS:
    ---%<---
    In 1.2 upstream added a test suite. We should run it during build
    (cd common && $(MAKE) test) but it needs to be able to write to the home directory, which is disabled on Debian auto-builders. Need to find
    a solution to that.
    %---

    To me it's clear what the problem is. The test requires a $HOME folder,
    but the build environment doesn't provide something like this.

    You nee to dive into the Debian package build process if you want to
    learn the "why". But this list is the wrong place for this.
    This list can help if you have specific questions about Python and
    Python packaging (as Mechtilde did mention).


    I don't understand what or who is blocking whom here?
    Is it that you feel you are blocked with your upstream work by the
    maintainer?
    [..]
    If you only think that the maintainer of backintime should be
    switched to the DPT then this is only a wish. And I don't think doing
    such a switch is improving the situation for you, still someone needs
    to do the work you requesting.

    All this is not about work in the meaning of fixing, uploading or
    something else. It is just about having a dialog. Without dialog I'm
    not able to learn and to take over packaging someday to save your
    resources. Not sure if it is against the Debian rules that upstream do
    its own Debian packaging.

    So you want and need to talk about how the Debian packaging is done? So
    you may be lucky to have some Debian folks around you which can explain
    this in one or more hacking session.

    Or you went to Debian Mentors.
    https://wiki.debian.org/DebianMentorsFaq
    https://mentors.debian.net/
    https://lists.debian.org/debian-mentors/

    This is the place there a few Debian contributors are willing to answer questions around that topic, but you wont find a ready to use HowTo for
    your case. Learning Debian packaging is more of a marathon run that
    doing a 4 week long intensive learning.

    Participating to Debian sometimes feels like talking to a wall. I want
    to learn and improve my skills to someday jump into the Debian
    packaging wheel. From my experience with this list it seems easier to
    have dialog with the DPT.

    May impression is simply you need to try to start in a much simpler way.
    You can not expect that a DD or DM is happy you tried to get in contact
    with him because of you have a problem as upstream.
    Your options as a non Debian Member are quite limited. And you currently
    not experienced enough to discuss things and try to enforce something.

    this then you are welcome to become a member of the DPT by doing work
    on packages which are in the maintenance of the DPT

    Exactly! That is why I want my package being switch from jmw to the DPT
    to make it "in the maintenance of the DPT".

    Sorry, but this is not your package! You are upstream, that's fine, but
    you want something to happen outside "your" world there you have no
    control of. We are here in Debian.

    ...
    I hope I made my point clear now that I want and still do this. E.g. I checked all debian bug tickets for backintime. But I'm not able doing
    this further when there is no dialog.

    I don't see the Debian Maintainer is wanting something from you as
    Upstream, so again, your expectation is wrong to me.
    There is a open report that the upstream test can't be running while
    build, if you can provide useful tips to solve this fine, if not than
    this is also o.k. The package isn't in bad and unusable state due the
    not running tests.

    I know this and I'm not that new to Debian. :)
    Waiting weeks and months for a reaction (not work) is IMHO not OK.

    For me it is. I have a real life beside Debian.

    --
    Regards
    Carsten

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From c.buhtz@posteo.jp@21:1/5 to All on Fri Jul 28 13:10:01 2023
    Dear Carsten,

    thanks for taking time and replying.

    Am 28.07.2023 11:53 schrieb Carsten Schoenert:
    you really should read the Social Contract/DFSG, the Debian policy and
    the Developers reference a few times.

    I'll do.

    There is no rule that any DD or DM *must* do something in Debian, so
    you probably have the wrong expectations.

    Fascinating.

    I don't see any workaround and there is non needed. The bug issue is
    about the not usable upstream test suite that would need to be called
    through d/rules.

    Maybe this is again about my expectations and wrong assumptions.

    So it is possible to have packages in the debian repo that don't run any
    tests? I wasn't expecting this.
    So Back In Time is in Debian for many years and never run tests on the
    Debian build system? I'm shocked.

    I didn't realize this. I thought that the test suite is broken and not
    it never works. ;)

    Having a package in the official Debian repo was always kind of a
    quality certificate for me. ;)

    Sorry, but this is not your package! You are upstream, that's fine,
    but you want something to happen outside "your" world there you have
    no control of. We are here in Debian.

    Understood.

    I don't see the Debian Maintainer is wanting something from you as
    Upstream, so again, your expectation is wrong to me.
    There is a open report that the upstream test can't be running while
    build, if you can provide useful tips to solve this fine

    What else can be done than making upstream fix the buggy tests. ;)

    Ubuntu

    :D No way!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon McVittie@21:1/5 to c.buhtz@posteo.jp on Fri Jul 28 14:40:02 2023
    On Fri, 28 Jul 2023 at 11:08:38 +0000, c.buhtz@posteo.jp wrote:
    Am 28.07.2023 11:53 schrieb Carsten Schoenert:
    I don't see any workaround and there is non needed. The bug issue is
    about the not usable upstream test suite that would need to be called through d/rules.

    Maybe this is again about my expectations and wrong assumptions.

    So it is possible to have packages in the debian repo that don't run any tests? I wasn't expecting this.
    So Back In Time is in Debian for many years and never run tests on the
    Debian build system? I'm shocked.

    Some packages can sensibly run tests at build-time, and for those packages,
    we usually try to do so. Some packages can't sensibly run tests at
    build-time (for instance if they need access to a GPU) so we don't; and
    for some packages we run tests at build-time, but we need to skip or ignore specific tests, or even ignore failure entirely, because the tests are
    known to be unreliable on some or all architectures.

    The only requirements on testing are:

    * the package's uploader has done whatever amount of automated or manual
    testing they feel is appropriate;
    * if automated tests *are* run, then they must succeed (or the failures
    must be explicitly ignored, if they're not believed to reflect a serious
    problem)
    * if the package runs build-time tests, they must meet the requirements in
    Policy (not writing to the user's home directory, not accessing the
    internet, etc.)

    If the uploader of backintime has tested it manually, either by running
    the test suite themselves or in real-world use of the updated package, then that's fine for an upload.

    smcv

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon McVittie@21:1/5 to Carsten Schoenert on Fri Jul 28 14:50:01 2023
    On Fri, 28 Jul 2023 at 11:53:29 +0200, Carsten Schoenert wrote:
    To quote from the BTS:
    ---%<---
    In 1.2 upstream added a test suite. We should run it during build
    (cd common && $(MAKE) test) but it needs to be able to write to the home directory, which is disabled on Debian auto-builders. Need to find
    a solution to that.
    %---

    To me it's clear what the problem is. The test requires a $HOME folder, but the build environment doesn't provide something like this.

    If backintime uses $HOME, and doesn't rely on $HOME being the same as
    $(getent passwd $(id -u)|cut -d: -f6), then it might actually be possible
    to run its test suite with a dependency on a suitably new debhelper.

    In debhelper compatibility level 13, dh_auto_test sets $HOME to a temporary directory (#942111) which might well be enough to run the test suite non-destructively. If that's sufficient, I'm sure the maintainer of the backintime package would appreciate a tested patch sent to #940319.
    The way to test this would be to build backintime in sbuild, with a uid
    whose "official" home directory in /etc/passwd doesn't exist in the chroot.

    The other angle this could be approached from is as an upstream developer:
    as an upstream, would you really want running the backintime test suite
    to make potentially destructive changes to your real home directory? As
    an upstream developer of other packages, I wouldn't want that: if I have
    made an implementation mistake, I want to be able to find out about that
    by running the test suite, knowing that the test suite won't damage my
    real home directory.

    Making the test suite write to a mock home directory instead of to the
    real home directory, and changing or unsetting environment variables that
    point to the real home directory (again, see #942111) during automated
    testing, would make the test suite safer and more predictable.

    smcv

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From c.buhtz@posteo.jp@21:1/5 to All on Fri Jul 28 15:00:01 2023
    Dear Simon,

    thanks for your thougths.

    Am 28.07.2023 14:44 schrieb Simon McVittie:
    The other angle this could be approached from is as an upstream
    developer:

    IMHO this is the only angle it should be approached from because it is upstreams responsibility and Debian shouldn't waste resources and
    solving other ones problems. ;)

    fake HOME directory

    To my defense I have to say I'm not the founder just a member of the
    current upstream maintenance team. I haven't written that tests. Using a
    fake file ystem or temp folder as HOME won't solve problems with the
    test suite because there is much more hidden in it. In summary despite
    some exceptions there are no unit tests just integration and system
    tests.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrey Rakhmatullin@21:1/5 to c.buhtz@posteo.jp on Fri Jul 28 15:40:01 2023
    On Fri, Jul 28, 2023 at 11:08:38AM +0000, c.buhtz@posteo.jp wrote:
    So it is possible to have packages in the debian repo that don't run any tests? I wasn't expecting this.
    Many packages don't have tests at all. For many of them tests are not
    possible or don't make much sense.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nicholas D Steeves@21:1/5 to Carsten Schoenert on Fri Jul 28 21:40:01 2023
    Carsten Schoenert <c.schoenert@t-online.de> writes:

    There is a private list there such information *can* be given, again,
    there is no rule that I need to do this.
    There are options if some other DD believes a package is needing an
    update, that process is called NMU (non maintainer upload). Or if you
    think the other maintainer isn't doing his work in a time able manner, a
    DD can salvage a package.
    But these options are only doable by DDs! And that for a reason.


    Yes, a new contributor requires a DD for sponsored uploads; however, new contributors are not discriminated against when salvaging a package.
    "Thanks to this [salvaging] process, new contributors should no longer
    be afraid to take over packages that have been neglected or entirely forgotten." https://www.debian.org/doc/manuals/developers-reference/pkgs.html#package-salvaging

    While it's true that no one can force anyone to do anything in Debian,
    it's also true that if someone salvages a chronically ignored package,
    that is a consequence of not having taken care of it, and then not
    having replied to the ITS bug for a month. All this assumes both good
    faith, and that new contributors educate themselves sufficiently well to
    submit upload candidates on debian-mentors (and file RFS) that
    sufficiently improves on the status quo of a neglected or forgotten
    package.

    It's important to note that the value expressed by this policy is that consistent, periodic (or better) long-term contributions are valued in
    Debian. It's also important to highlight that this value is attainable
    as a Debian Maintainer (uploading a set of approved packages), or as a
    Debian Contributor who requires a sponsor for all uploads.

    Best,
    Nicholas

    --=-=-Content-Type: application/pgp-signature; name="signature.asc"

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

    iQJEBAEBCgAuFiEE4qYmHjkArtfNxmcIWogwR199EGEFAmTEGRYQHHN0ZW5AZGVi aWFuLm9yZwAKCRBaiDBHX30QYZ8qD/4wsYCj8KDItqPq0AedjGnuPKnJmpvBkrqz RlCypy5f62kbzE6J8KL3oXGjkGeXpV0fnXsxY0r3U0wqxfVErrxGEAMvGcB5vj/H 4IK3TQB1wUo0wPIRNTAVShJvKLdKLrNshv+KZeVqtW35+mnolT9c8MSWDbtW2vAD Qdgycw0x85yOltNZHaXoXJL4jkOgCBryKj7+Uboa+u0AekikiZ0jeDB/nQYAVh5+ UWQocfEfFAdX6eUrosGUIEbNbxbtW1ts9FnI9u8ogWwXktD/Cl343LOwr8iuCYkH SZpruaz69X8j3e3VVK0+h3oUtgBtNK71/N50/zGYBkI97ENYKhKvJ1Ql3ynIv4P8 shfAroALLZoh5jOCtWqqt40u19QaxN7Y9cRUBYCiNnpZcl7BD3c/s0zawNtEK12w SDqYIKe3ZOVdpbjdX58lZDiN05dYvU1vI0yhq+mc0stWehTTdRH9dXrOxaI8l68Y IVPG/0Csw2U0BhKIbrbTQzgHlbUZpwGAz3E5b6J7TBnVF7sG7piGluZw/RkPs92h mEe5wdqD+gN6VKObnVQz8r+bJTb6jOxSIh/WEzst+Ys10bNQujnuIPJkkbC7e+J7 RZPA+VJhksJS8pF00+mTrjvcQC9qWRHDxnEMKOgN56VeYwwncARB76KfVP32KiKD
    QCc1yviO+w=u4Q
    -----END PGP SIGNATURE-----

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