• Re: Misc Developer News (#58)

    From Marian Brockerhoff@21:1/5 to pabs@debian.org on Thu Nov 24 17:50:01 2022
    remove me from the email list please
    regards,

    On Mon, Nov 21, 2022 at 12:19 AM Paul Wise <pabs@debian.org> wrote:

    The news are collected on https://wiki.debian.org/DeveloperNews
    Please contribute short news about your work/plans/subproject.

    In this issue:
    + anacron might be disabled if 2.3-33 was ever installed
    + riscv64 porterbox
    + porterbox DNS alias maintainers needed
    + debtags.d.o maintainers needed
    + lintian contributors needed
    + Experimental manual migration pseudo-excuses
    + CPU instruction selection documentation

    anacron might be disabled if 2.3-33 was ever installed ------------------------------------------------------

    If you run Debian testing/unstable and ever installed anacron 2.3-33 on
    a systemd based system, then anacron will no longer be enabled and the
    daily/weekly/monthly cron jobs will not be run until it is.

    Since not all cron jobs have migrated to systemd timers, Debian
    testing/unstable systems with systemd and anacron may be missing
    some essential cron jobs, such as making backups of aptitude state.

    To see if a system is affected you can use these commands:

    zgrep -i anacron.*2.3-33 /var/log/apt/history.log*
    systemctl status anacron.service anacron.timer

    To re-enable anacron you can use these commands:

    sudo systemctl enable anacron.service anacron.timer
    sudo systemctl start anacron.service anacron.timer

    More details of this problem are available in these bugs:

    https://bugs.debian.org/1019554
    https://bugs.debian.org/1020966
    https://bugs.debian.org/1021496

    -- Paul Wise

    riscv64 porterbox
    -----------------

    There is now a porterbox for riscv64[1] available for Debian contributors
    to use[2] for porting packages to RISC-V.

    Thanks to SiFive for providing the HiFive Unmatched board, OSUOSL for
    assembling and hosting the hardware and Aurélien Jarno and Manuel A.
    Fernandez Montecelo for installing/setting up/admining the porterbox.

    -- Paul Wise

    [1] https://blog.aurel32.net/riscv64-porterbox.html
    [2] https://wiki.debian.org/PorterBoxHowToUse

    porterbox DNS alias maintainers needed
    --------------------------------------

    Jakub Wilk has mentioned[3] that the DNS aliases to Debian porterboxes are
    now unmaintained and in need of new maintainers.

    -- Paul Wise

    [3] https://lists.debian.org/msgid-search/20221107213046.atgukd2iogsaynxo@jwilk.net

    debtags.d.o maintainers needed
    ------------------------------

    Enrico Zini has announced debtags.d.o[4] is in need of new maintainers
    and will be shut down if none are forthcoming.

    -- Paul Wise

    [4] https://lists.debian.org/msgid-search/20221019132043.d4c4liyt6s6qewgy@enricozini.org

    lintian contributors needed
    ---------------------------

    The primary lintian contributors have stopped[5] working[6] on it. Axel
    Beckert has stepped up[7] to provide maintenance work, but requests help
    adding new tags, performance tuning and other important work.

    If you are interested in working on it, please join the lintian group on
    salsa[8] (DD will be accepted instantly, non-DD should show some
    contributions first, e.g. via Merge Requests), add yourself to the
    lintian team wiki page[9], join the debian-lint-maint[10] mailing list,
    and review the bugs filed against lintian[11], issues on salsa[12] and
    merge requests on salsa (1[13] 2[14]).

    -- Paul Wise + Axel Beckert

    [5] https://lists.debian.org/msgid-search/5e4d0e28-a3f4-4302-8364-5afd93d8ae17@www.fastmail.com
    [6] https://lists.debian.org/msgid-search/CAFHYt550_6hc-2SRjqYv0z9kgpWuLpGnnxVOonPOHP3R+pAQZA@mail.gmail.com
    [7] https://bugs.debian.org/1012289
    [8] https://salsa.debian.org/lintian
    [9] https://wiki.debian.org/Teams/Lintian
    [10] https://lists.debian.org/debian-lint-maint/
    [11] https://bugs.debian.org/src:lintian
    [12] https://salsa.debian.org/groups/lintian/-/issues
    [13] https://salsa.debian.org/lintian/lintian/-/merge_requests
    [14] https://salsa.debian.org/groups/lintian/-/merge_requests

    Experimental manual migration pseudo-excuses --------------------------------------------

    The experimental pseudo-excuses[15] (warning: large file) help
    maintainers discover problems that will be introduced when they manually
    migrate packages from experimental to unstable. These excuses are now
    imported into the Debian QA excuses page[16], which allows checking
    individual package excuses for testing migration and now also
    pseudo-excuses for experimental manual migration. This is much more
    convenient than loading the very large excuses and pseudo-excuses HTML
    files. Help[17] is needed[18] from Python/Django developers to integrate
    the pseudo-excuses into the Debian Package Tracker[19], see the guide to
    contributing[20] if you would like to help.

    [15] https://release.debian.org/britney/pseudo-excuses-experimental.html
    [16] https://qa.debian.org/excuses.php
    [17] https://bugs.debian.org/944737
    [18] https://bugs.debian.org/991237
    [19] https://tracker.debian.org
    [20] https://qa.pages.debian.net/distro-tracker/contributing.html

    CPU instruction selection documentation ---------------------------------------

    New documentation has been written summarising all the options for
    selection of CPU instructions[21], including porting between SIMD
    instructions, emulating atomic instructions, manual runtime code path
    selection, manual runtime function selection, compiler function
    multi-versioning, glibc hwcaps library selection, runtime binary
    selection, blocking installation and blocking running binaries. When you
    discover a package has limited portability due to a higher baseline, use
    of SIMD/atomic instructions, or other CPU instruction related problem,
    please consider perusing the new documentation, improving the portability
    using the documented techniques and contributing your changes upstream
    where possible. If you see others discovering these issues, please
    suggest they take a look at the documentation.

    -- Paul Wise, Gioele Barabucci and Bastien Roucaries

    [21] https://wiki.debian.org/InstructionSelection

    --
    bye,
    pabs

    https://wiki.debian.org/PaulWise


    <div dir="ltr"><div> remove me from the email list please<br></div>regards,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 21, 2022 at 12:19 AM Paul Wise &lt;<a href="mailto:pabs@debian.org">pabs@debian.org</a>&gt;
    wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The news are collected on <a href="https://wiki.debian.org/DeveloperNews" rel="noreferrer" target="_blank">https://
    wiki.debian.org/DeveloperNews</a><br>
    Please contribute short news about your work/plans/subproject.<br>

    In this issue:<br>
     + anacron might be disabled if 2.3-33 was ever installed<br>
     + riscv64 porterbox<br>
     + porterbox DNS alias maintainers needed<br>
     + debtags.d.o maintainers needed<br>
     + lintian contributors needed<br>
     + Experimental manual migration pseudo-excuses<br>
     + CPU instruction selection documentation<br>

    anacron might be disabled if 2.3-33 was ever installed<br> ------------------------------------------------------<br>

     If you run Debian testing/unstable and ever installed anacron 2.3-33 on<br>  a systemd based system, then anacron will no longer be enabled and the<br>  daily/weekly/monthly cron jobs will not be run until it is.<br>

     Since not all cron jobs have migrated to systemd timers, Debian<br>  testing/unstable systems with systemd and anacron may be missing<br>
     some essential cron jobs, such as making backups of aptitude state.<br>

     To see if a system is affected you can use these commands:<br>

        zgrep -i anacron.*2.3-33 /var/log/apt/history.log*<br>
        systemctl status anacron.service anacron.timer<br>

     To re-enable anacron you can use these commands:<br>

        sudo systemctl enable anacron.service anacron.timer<br>
        sudo systemctl start anacron.service anacron.timer<br>

     More details of this problem are available in these bugs:<br>

        <a href="https://bugs.debian.org/1019554" rel="noreferrer" target="_blank">https://bugs.debian.org/1019554</a><br>
        <a href="https://bugs.debian.org/1020966" rel="noreferrer" target="_blank">https://bugs.debian.org/1020966</a><br>
        <a href="https://bugs.debian.org/1021496" rel="noreferrer" target="_blank">https://bugs.debian.org/1021496</a><br>

      -- Paul Wise<br>

    riscv64 porterbox<br>
    -----------------<br>

     There is now a porterbox for riscv64[1] available for Debian contributors<br>  to use[2] for porting packages to RISC-V.<br>

     Thanks to SiFive for providing the HiFive Unmatched board, OSUOSL for<br>  assembling and hosting the hardware and Aurélien Jarno and Manuel A.<br>  Fernandez Montecelo for installing/setting up/admining the porterbox.<br>

      -- Paul Wise<br>

     [1] <a href="https://blog.aurel32.net/riscv64-porterbox.html" rel="noreferrer" target="_blank">https://blog.aurel32.net/riscv64-porterbox.html</a><br>
     [2] <a href="https://wiki.debian.org/PorterBoxHowToUse" rel="noreferrer" target="_blank">https://wiki.debian.org/PorterBoxHowToUse</a><br>

    porterbox DNS alias maintainers needed<br> --------------------------------------<br>

     Jakub Wilk has mentioned[3] that the DNS aliases to Debian porterboxes are<br>
     now unmaintained and in need of new maintainers.<br>

      -- Paul Wise<br>

     [3] <a href="https://lists.debian.org/msgid-search/20221107213046.atgukd2iogsaynxo@jwilk.net" rel="noreferrer" target="_blank">https://lists.debian.org/msgid-search/20221107213046.atgukd2iogsaynxo@jwilk.net</a><br>

    debtags.d.o maintainers needed<br>
    ------------------------------<br>

     Enrico Zini has announced debtags.d.o[4] is in need of new maintainers<br>  and will be shut down if none are forthcoming.<br>

      -- Paul Wise<br>

     [4] <a href="https://lists.debian.org/msgid-search/20221019132043.d4c4liyt6s6qewgy@enricozini.org" rel="noreferrer" target="_blank">https://lists.debian.org/msgid-search/20221019132043.d4c4liyt6s6qewgy@enricozini.org</a><br>

    lintian contributors needed<br>
    ---------------------------<br>

     The primary lintian contributors have stopped[5] working[6] on it. Axel<br>  Beckert has stepped up[7] to provide maintenance work, but requests help<br>  adding new tags, performance tuning and other important work.<br>

     If you are interested in working on it, please join the lintian group on<br>  salsa[8] (DD will be accepted instantly, non-DD should show some<br>  contributions first, e.g. via Merge Requests), add yourself to the<br>  lintian team wiki page[9], join the debian-lint-maint[10] mailing list,<br>  and review the bugs filed against lintian[11], issues on salsa[12] and<br>  merge requests on salsa (1[13] 2[14]).<br>

      -- Paul Wise + Axel Beckert<br>

     [5] <a href="https://lists.debian.org/msgid-search/5e4d0e28-a3f4-4302-8364-5afd93d8ae17@www.fastmail.com" rel="noreferrer" target="_blank">https://lists.debian.org/msgid-search/5e4d0e28-a3f4-4302-8364-5afd93d8ae17@www.fastmail.com</a><br>
     [6] <a href="https://lists.debian.org/msgid-search/CAFHYt550_6hc-2SRjqYv0z9kgpWuLpGnnxVOonPOHP3R+pAQZA@mail.gmail.com" rel="noreferrer" target="_blank">https://lists.debian.org/msgid-search/CAFHYt550_6hc-2SRjqYv0z9kgpWuLpGnnxVOonPOHP3R+pAQZA@mail.gmail.
    com</a><br>
     [7] <a href="https://bugs.debian.org/1012289" rel="noreferrer" target="_blank">https://bugs.debian.org/1012289</a><br>
     [8] <a href="https://salsa.debian.org/lintian" rel="noreferrer" target="_blank">https://salsa.debian.org/lintian</a><br>
     [9] <a href="https://wiki.debian.org/Teams/Lintian" rel="noreferrer" target="_blank">https://wiki.debian.org/Teams/Lintian</a><br>
     [10] <a href="https://lists.debian.org/debian-lint-maint/" rel="noreferrer" target="_blank">https://lists.debian.org/debian-lint-maint/</a><br>
     [11] <a href="https://bugs.debian.org/src:lintian" rel="noreferrer" target="_blank">https://bugs.debian.org/src:lintian</a><br>
     [12] <a href="https://salsa.debian.org/groups/lintian/-/issues" rel="noreferrer" target="_blank">https://salsa.debian.org/groups/lintian/-/issues</a><br>
     [13] <a href="https://salsa.debian.org/lintian/lintian/-/merge_requests" rel="noreferrer" target="_blank">https://salsa.debian.org/lintian/lintian/-/merge_requests</a><br>
     [14] <a href="https://salsa.debian.org/groups/lintian/-/merge_requests" rel="noreferrer" target="_blank">https://salsa.debian.org/groups/lintian/-/merge_requests</a><br>

    Experimental manual migration pseudo-excuses<br> --------------------------------------------<br>

     The experimental pseudo-excuses[15] (warning: large file) help<br>  maintainers discover problems that will be introduced when they manually<br>  migrate packages from experimental to unstable. These excuses are now<br>  imported into the Debian QA excuses page[16], which allows checking<br>  individual package excuses for testing migration and now also<br>  pseudo-excuses for experimental manual migration. This is much more<br>  convenient than loading the very large excuses and pseudo-excuses HTML<br>  files. Help[17] is needed[18] from Python/Django developers to integrate<br>  the pseudo-excuses into the Debian Package Tracker[19], see the guide to<br>  contributing[20] if you would like to help.<br>

     [15] <a href="https://release.debian.org/britney/pseudo-excuses-experimental.html" rel="noreferrer" target="_blank">https://release.debian.org/britney/pseudo-excuses-experimental.html</a><br>
     [16] <a href="https://qa.debian.org/excuses.php" rel="noreferrer" target="_blank">https://qa.debian.org/excuses.php</a><br>
     [17] <a href="https://bugs.debian.org/944737" rel="noreferrer" target="_blank">https://bugs.debian.org/944737</a><br>
     [18] <a href="https://bugs.debian.org/991237" rel="noreferrer" target="_blank">https://bugs.debian.org/991237</a><br>
     [19] <a href="https://tracker.debian.org" rel="noreferrer" target="_blank">https://tracker.debian.org</a><br>
     [20] <a href="https://qa.pages.debian.net/distro-tracker/contributing.html" rel="noreferrer" target="_blank">https://qa.pages.debian.net/distro-tracker/contributing.html</a><br>

    CPU instruction selection documentation<br> ---------------------------------------<br>

     New documentation has been written summarising all the options for<br>  selection of CPU instructions[21], including porting between SIMD<br>  instructions, emulating atomic instructions, manual runtime code path<br>  selection, manual runtime function selection, compiler function<br>  multi-versioning, glibc hwcaps library selection, runtime binary<br>  selection, blocking installation and blocking running binaries. When you<br>  discover a package has limited portability due to a higher baseline, use<br>  of SIMD/atomic instructions, or other CPU instruction related problem,<br>  please consider perusing the new documentation, improving the portability<br>  using the documented techniques and contributing your changes upstream<br>  where possible. If you see others discovering these issues, please<br>  suggest they take a look at the documentation.<br>

      -- Paul Wise, Gioele Barabucci and Bastien Roucaries<br>

     [21] <a href="https://wiki.debian.org/InstructionSelection" rel="noreferrer" target="_blank">https://wiki.debian.org/InstructionSelection</a><br>

    -- <br>
    bye,<br>
    pabs<br>

    <a href="https://wiki.debian.org/PaulWise" rel="noreferrer" target="_blank">https://wiki.debian.org/PaulWise</a><br>
    </blockquote></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bastian Venthur@21:1/5 to Paul Wise on Fri Nov 25 12:50:01 2022
    On 21.11.22 00:18, Paul Wise wrote:
    [...]
    anacron might be disabled if 2.3-33 was ever installed ------------------------------------------------------

    If you run Debian testing/unstable and ever installed anacron 2.3-33 on
    a systemd based system, then anacron will no longer be enabled and the
    daily/weekly/monthly cron jobs will not be run until it is.

    Since not all cron jobs have migrated to systemd timers, Debian
    testing/unstable systems with systemd and anacron may be missing
    some essential cron jobs, such as making backups of aptitude state.

    To see if a system is affected you can use these commands:

    zgrep -i anacron.*2.3-33 /var/log/apt/history.log*
    systemctl status anacron.service anacron.timer

    To re-enable anacron you can use these commands:

    sudo systemctl enable anacron.service anacron.timer
    sudo systemctl start anacron.service anacron.timer

    I'm having trouble assessing the severity of the situation. Is more or
    less everyone affected who uses unstable? If yes, how do we mitigate?
    Don't think the majority of users reads the announcement mails.


    Cheers,

    Bastian

    --
    Dr. Bastian Venthur https://venthur.de
    Debian Developer venthur at debian org

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Wise@21:1/5 to Bastian Venthur on Thu Dec 1 10:10:01 2022
    On Fri, 2022-11-25 at 12:46 +0100, Bastian Venthur wrote:
    On 21.11.22 00:18, Paul Wise wrote:
    anacron might be disabled if 2.3-33 was ever installed
    [...]
    I'm having trouble assessing the severity of the situation. Is more or
    less everyone affected who uses unstable? If yes, how do we mitigate?

    Every system with task-laptop, parl-desktop, ipmiutil or octavia-agent
    will have anacron. There are also recommends from task-desktop,
    cinnamon-core, email-reminder. The other reverse deps are alternatives.

    The problematic anacron version was in unstable from 2022-07-13 to
    2022-09-04 and in testing from 2022-07-20 to 2022-09-05, as that is
    ~1.5 months, probably most unstable/testing anacron installs are
    affected, since they probably did an upgrade during that time.

    https://tracker.debian.org/pkg/anacron

    Don't think the majority of users reads the announcement mails.

    The maintainer has stated that they don't intend any further actions,
    so I thought it important that the issue be announced more widely.
    So this was also announced via debian-user and micronews, but I suspect
    you are right that not all unstable/testing users will hear about it.

    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019554#175 https://lists.debian.org/msgid-search/1033e8644f1658da6c8526f15de58264d7ab441d.camel@debian.org
    https://micronews.debian.org/2022/1669045429.html https://micronews.debian.org/2022/1669126914.html

    --
    bye,
    pabs

    https://wiki.debian.org/PaulWise

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

    iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmOIbd8ACgkQMRa6Xp/6 aaNGlQ//XIhXB6HUzAScM2oUFJG6CrCVVvfeMtqsrKF3Y6+6nuePqwNhJ1K7Zw+f jg6Oqj173XSwMnDlc+hnJA7KzcrvbeVTvMF8EyMjP0mhoyg7jn1F2tegURJVEJoF pYSyGfotiIWTFH5xpmg3zXziNIcPITd1IbdSJJx+fLUsUX8dwwxnFlAxKcEkg3Xi HAUSgJnxxwg3rLEwA72jPFhMhmFOhfSqKIhOKAQseXpU0iGXOHiG88z/mAJT5QkI 7KIfqBTkBuuTxH7Zqmi6r57j2oIqqREqICpi8GlF7n4gT2FKpg7KUS2ZrSz7Nsc8 56nimVT6iKeUDg53qLry8yMpP8EAug7pfUHyLvNRV+2acijfosqQDmq8ZV0H+HGj T9wkMGpXt0z/WMpdg9CpTkCl9fQa86EdBNz4KW0sL/d7U5MD2yyLUsBYK14TA3Jh JwVTb/1OYW76bUV9F3eXQuCmLY8r7GrY/RjJ+/yvpwyZnT44yLqjMG/79AOO+fjz 0u90tNZ5uI7cP3LJpgA5OWtlkmNRALjeuZJ2fnVyoNCMpI1QVcYdkBmV/LEX3MNQ ysVtgmvbNHr7QXlKlGYmgG7Hxpf5pMjXSeTw9ycEyRpP7bB800Bw6RfB01GzQQlw sOwwo+Oq51D9yC6lpm95eFgo8e/bq4I9GURFzP4NO0aP9ihnYwA=
    =3FzM
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bastian Venthur@21:1/5 to Paul Wise on Thu Dec 1 11:50:01 2022
    On 01.12.22 10:03, Paul Wise wrote:
    On Fri, 2022-11-25 at 12:46 +0100, Bastian Venthur wrote:
    On 21.11.22 00:18, Paul Wise wrote:
    anacron might be disabled if 2.3-33 was ever installed
    [...]
    I'm having trouble assessing the severity of the situation. Is more or
    less everyone affected who uses unstable? If yes, how do we mitigate?

    Every system with task-laptop, parl-desktop, ipmiutil or octavia-agent
    will have anacron. There are also recommends from task-desktop, cinnamon-core, email-reminder. The other reverse deps are alternatives.

    The problematic anacron version was in unstable from 2022-07-13 to
    2022-09-04 and in testing from 2022-07-20 to 2022-09-05, as that is
    ~1.5 months, probably most unstable/testing anacron installs are
    affected, since they probably did an upgrade during that time.

    https://tracker.debian.org/pkg/anacron

    Thanks for the analysis!

    Don't think the majority of users reads the announcement mails.

    The maintainer has stated that they don't intend any further actions,
    so I thought it important that the issue be announced more widely.

    Good call, thank you!

    So this was also announced via debian-user and micronews, but I suspect
    you are right that not all unstable/testing users will hear about it.

    I agree. I'd go even further and assume not even the majority of users
    follows these channels so most of them are likely to be affected.

    I wonder if there's an easy fix here, like a new version of anacron that
    adds a check for this particular issue, offering to fix it during
    upgrade of the package.


    Cheers,

    Bastian



    --
    Dr. Bastian Venthur https://venthur.de
    Debian Developer venthur at debian org

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Wise@21:1/5 to Bastian Venthur on Thu Dec 1 14:20:01 2022
    On Thu, 2022-12-01 at 11:42 +0100, Bastian Venthur wrote:

    I wonder if there's an easy fix here, like a new version of anacron that adds a check for this particular issue, offering to fix it during
    upgrade of the package.

    It is hard to tell the difference between an affected system and one
    where the admin manually disabled anacron. The only solution I can
    think of would be to add 2.3-36 that forcibly re-enables anacron on
    systemd systems when upgrading from 2.3-33, 2.3-34 or 2.3-35. This
    might be a reasonable compromise, since only systems with those
    versions could be affected and hopefully not very many sid/bookworm
    systems have anacron deliberately disabled anyway. A message from the
    postinst in the upgrade log and or a NEWS.Debian item could notify
    admins of the fix. The workaround can be dropped after some months.

    PS: I don't intend to work on this myself.

    --
    bye,
    pabs

    https://wiki.debian.org/PaulWise

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

    iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmOIqIYACgkQMRa6Xp/6 aaPsUw/+Nxg1pC3TcGcCCQyUusBHUio8WOAiqNY9TMABzUA4XxCPgj8bC7FJhhNQ U7mVwyO7DLc1BCVLE7yVmk4SxpBkStqNPG6W0E2GKJo+7ZuoiO+dYj1xDRw9qAC4 FsTgaBtE4UaL+PNJIt2xPZ5THnNw4ZeeHgiosO5umTJ6zmJ3qAKqAHDlNHLHyE0j /qI085glEeWe2SPWajCKIrlpnC4itlUcdt2ONk3z+NQHT1rpTJzxbEx7V8m2BkSM W/9nDE+mb/rDtZOn67U/r4NoB6e4ZDU6ON/tMFtlI87QvOR+fugBW4xLp+2EXOw/ MiLEG5qUSmQLDMAwzhbYi5/sHTl2cYxEghttSWb9CsOTdjB+0ZywZFICT/9LdYOb 4YuLrj0HwewVtUPfbdxsrzAhkqi1qHxQyOrK8duEQ+eQMPSA0zpmZvTZ1jO3fDQD /x+RtPQSnyEmE+hHQjZFUHHsoeDDz4/xaf7NiGwGIsSzFUchGmB9m1VD3ZzGbIFO 6KySP+fDbNWu1nUeYXzErv1r/wpu9QZmIYFlTEEpzLov4xdfzsX3D57Vw339+YQP x+8C9patVJuI+azpDVNRZzcp4qpe/8GHPfncrGQytlI0RIdCdyEWthnTr/sPi0zp eOdgaaLkGFAla8W2ZPNNryQBsWGPkhk+AjUHdd9Sqxi4D+vP30A=
    =VJns
    -----END PGP SIGNATURE-----

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