1. Forum
  2. Usenet
  3. LINUX.DEBIAN.DEVEL

  • Re: Will i386 released for Trixie and if no can we stop working on it n

    From Paul Gevers@21:1/5 to All on Sun Oct 13 16:30:02 2024
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------uQGpPIN7Id09hHqXwhTdfxgQ
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

    SGksDQoNCj4gSXQgc2VlbXMgdGhhdCBpdCBpcyBmYWxsaW5nIGFwcGFydCBwaWVjZSBieSBw aWVjZSwgYnV0IG9uIHRoZSBvdGhlcg0KPiBoYW5kLCBpdCBpcyBzdGlsbCBhIHJlbGVhc2Ug YXJjaGl0ZWN0dXJlLCBtZWFuaW5nIHRoYXQgZm9yIGFyY2g6YW55DQo+IHBhY2thZ2VzIHRo YXQgZG8gbm90IHN1cHBvcnQgaXQgdGhlIHJhbmRvbSBEZWJpYW4gRGV2ZWxvcGVyIG5lZWRz IHRvIGRvDQo+IGEgbG90IG9mIG1hbnVhbCB3b3JrLCBidWcgbWFuYWdlbWVudCwgdXBsb2Fk cywgcmV2ZXJzZS1kZXBlbmRlbmN5IGNoYWluDQo+IHRyYXZlcnNhbHMsIEZUUCBtYXN0ZXIg cmVtb3ZlbCByZXF1ZXN0cywgZXRjLiAgUGx1cyBlbmR1cmluZyB0aGUgYW54aWV0eQ0KPiBv ZiB3b3JyeWluZyB0byBjYXJyeSBzb21lIHNvY2lhbCBzdHlnbWEgZmlyIG5vdCBkb2luZyBl bm91Z2ggdG8gc3VwcG9ydA0KPiBub24tYW1kNjQgYXJjaGl0ZWN0dXJlcy4NCj4gDQo+IENh biB3ZSBvcmdhbmlzZSBvdXJzZWx2ZXMgc28gdGhhdCB3aGF0ZXJ2ZXIgdGhlIGZ1dHVyZSBv ZiBpMzg2IGlzLCBpdA0KPiBkb2VzIG5vdCBjb25zdW1lIHVucGFpZCB2b2x1bnRlZXIgd29y ayBmb3Igbm90aGluZyA/ICBJZiB0aGUga2VybmVsIHRlYW0NCj4gYW5kIHRoZSBpbnN0YWxs ZXIgdGVhbSBjb3VsZCB3aXRoZHJhdyBzdXBwb3J0LCBjYW4gdGhlIHBhY2thZ2UNCj4gbWFp bnRhaW5lcnMgb2Ygc2NpZW50aWZpYyBjb21wdXRpbmcgc29mdHdhcmUgZG8gc28gdG9vPyAg SXMgdGhlcmUgYSB3YXkNCj4gdG8gZG8gaXQgaW4gYSBzaW5nbGUgb3BlcmF0aW9uIGluc3Rl YWQgb2YgZmlsbGluZyBwbGVudHkgb2YgYnVncyBhbmQNCj4gbW9kaWZ5aW5nIHBsZW50eSBv ZiBkZWJpYW4vY29udHJvbCBmaWxlcz8gIExpZmUgaXMgdG9vIHNob3J0IHRvIHNwZW5kDQo+ IG91ciB0aW1lIG9uIGRvaW5nIHRoYXQuDQoNClN0YXRlbWVudCBmcm9tIHRoZSBSZWxlYXNl IFRlYW06DQoNCmh0dHBzOi8vbGlzdHMuZGViaWFuLm9yZy9kZWJpYW4tZGV2ZWwtYW5ub3Vu Y2UvMjAyMy8xMi9tc2cwMDAwMy5odG1sDQoNClBhdWwNCg0K

    --------------uQGpPIN7Id09hHqXwhTdfxgQ--

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

    wsB5BAABCAAjFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAmcL11cFAwAAAAAACgkQnFyZ6wW9dQoa 9gf/RsonncoMfUYYN2eC0Tz4z5MLELjcYJy37TwVUaJlayTXJDGNGDnVZTKDxyOp5FgwFJYUgtTA kPellC+v9M8Yk2Sr83cLJCrNSoiutjU4OoAQGONCh78SDgByoLD6Day0bymrbXuTE3FaiCOpMwUI P8+K+spm9Iv096VQUPNzkRkR47+5zBRphvvr8rOoWAWUO2SyQO1l54/iodAXTMewiXObMLy1OPEA aIBpdQHqDQQc6PEc6zyxW3gGGupKBqS2n0KiXiYdaDtFUTQYGrU2O+fHNy17h14EpGwAoFGznH2x vMOW0R1BXMzpWJX9XSVylSnRyj1tx2ItFH5odFQgug==
    =QcVU
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Charles Plessy@21:1/5 to All on Sun Oct 13 16:40:01 2024
    Le Sun, Oct 13, 2024 at 03:21:11PM +0100, Paul Gevers a écrit :

    https://lists.debian.org/debian-devel-announce/2023/12/msg00003.html

    Thanks, I read it at the time but I did not understand the meaning:

    do you really expect that we progressively edit thousands of
    debian/control files and file thousands of FTP removal bugs?

    To be frank, the result of your current policy is that, defensively, I
    take the opportunity of dropping 32-bit support as a whole instead of
    i386 specifically because a) it is easier (just build depend on architecture-is-64-bit), and b) the prospect of re-doing for other
    32-bit arches what we do for i386 is really making feel like running
    away from Debian.

    I am not complaining about effort to keep useful i386 packages in
    Debian, but about the lack of tools to remove the other i386 packages
    in a smarter ways. Can we not just have a way to send a signed email
    to a bot somewhere with a list of packages, and voilà, they are
    removed seamlessly and we can focus on other tasks?

    Have a nice day

    Chares

    --
    Charles Plessy Nagahama, Yomitan, Okinawa, Japan
    Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://fediscience.org/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marc Haber@21:1/5 to All on Sun Oct 13 17:30:01 2024
    On Sun, 13 Oct 2024 23:37:11 +0900, Charles Plessy <plessy@debian.org>
    wrote:
    Le Sun, Oct 13, 2024 at 03:21:11PM +0100, Paul Gevers a écrit :

    https://lists.debian.org/debian-devel-announce/2023/12/msg00003.html

    Thanks, I read it at the time but I did not understand the meaning:

    it means that packages will still be built for i386 unless their
    maintainer decides differently. There will probably be no i386
    installer and no i386 kernel, but you still can have i386 in a
    container or as multiarch, both on amd64 host systems.

    do you really expect that we progressively edit thousands of
    debian/control files and file thousands of FTP removal bugs?

    I think that I will be way to lazy to drop i386 support for a package
    the builds on i386 and will run there. I do not expect that any of my
    packages will give me trouble on i386 for the time being.

    Greetings
    Marc
    --
    ---------------------------------------------------------------------------- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " |
    Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Holger Levsen@21:1/5 to Charles Plessy on Mon Oct 14 10:30:01 2024
    On Sun, Oct 13, 2024 at 11:37:11PM +0900, Charles Plessy wrote:
    Le Sun, Oct 13, 2024 at 03:21:11PM +0100, Paul Gevers a écrit :
    https://lists.debian.org/debian-devel-announce/2023/12/msg00003.html
    Thanks, I read it at the time but I did not understand the meaning:
    do you really expect that we progressively edit thousands of
    debian/control files and file thousands of FTP removal bugs?

    no, I don't think so.

    I am not complaining about effort to keep useful i386 packages in
    Debian, but about the lack of tools to remove the other i386 packages
    in a smarter ways. Can we not just have a way to send a signed email
    to a bot somewhere with a list of packages, and voilà, they are
    removed seamlessly and we can focus on other tasks?

    merely dropping i386 support for a package is not what https://lists.debian.org/debian-devel-announce/2023/12/msg00003.html asks/offers you to do, which is *coordinating with reverse (build) dependencies first*.


    --
    cheers,
    Holger

    ⢀⣴⠾⠻⢶⣦⠀
    ⣾â â¢ â ’⠀⣿⡠holger@(debian|reproducible-builds|layer-acht).org
    ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
    ⠈⠳⣄

    It started as a virus and has mutated into an IQ test.

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

    iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmcM1iAACgkQCRq4Vgaa qhwJHBAAhC21Pos44Z0+G2/R9Z5T1Gthfqb9+724utD5EQ/xhKtn0+rQlaK1MfZt B5rqdPjT4JK2VA/T0pGU5hcKFauoposDWkqNgZrAUGQITxCqmHmRWLj7x+ONoFMh ajA4cdADieQLWq/9+oJ5y0GWJ5eN3Buvmnw6hk9JoJwBMIg8N2bBPCy9ltj1nyt6 4gQdz8SufPEKrHj38E+yepZ49HGxdhg5DWuwgNC0hjPUF/Z6Srrn6ib9DkjSjl+V MvK9VGJHJizDUwlky28SM8ihgVqLpPwMWA75DcZCpo9Fe4TA9KHfUzN0c0lqlIE/ J6iTbq6T1V4kzvrJeFvmlz07bGdLlmSNWQPCWO2l5VMqzHjL93YVk/1nCrLQ8/Sh PBv/eRter9GA0Ah03KbsLBo7pbQXoZDoKP30B64Qqu9NpnJrnGb/C2y1pkCZFB7t JkBsbAVLdQI0gRuUqmCE1mvmQ0gti8g2ky8xywFF7lx0UWcAjeWufKsE6Rqv0L1m EtWFLAfAf8+r3AeP4QFQG1r0c3P3e2vV8u9QnEVqZZGvHS44FLRiFBVWJjBxkSAc Iq963GMV14CKJD7Hcww0nckHd6cGSqz6UI9Ds4u3W7aviodPuYFkYPPByW
  • From Charles Plessy@21:1/5 to All on Mon Oct 14 14:50:01 2024
    TL;DR: bitrotting, crumbling, extra work, help

    Hi Holger and everybody,

    The reason I am unhappy about the way i386 is managed is that I am part
    of a packaging team that maintains more than 500 architecture-dependent packages, and I see that upstreams compatibility with i386 (and all
    32-bit arches, to be honest) is in the process of bitrotting. Many
    packages have reverse-dependencies only within the team. The need
    for support removal pops up randomly, it is out of my control and very disempowering.

    The package names starts with r-cran. Upstream, they are tested against
    amd64 and Silicon only. If you look at the health of the packages and
    the team, it is not good. Well it is as good as many pieces of the free software ecocystem: crumbling under the weight.

    Let's look at the options for i386:

    - Remove it from released architectures. Treat is like other
    non-release ports: Architecture: any builds them, but build
    failures or CI regressions are not release-critical.
    - Keep some packages to be installed as multi-arch or chroot,
    opt-in. This is extra work for the maintainers of packages
    opting in.
    - Same but opt-out. This is extra work for opting out.

    In my opinion, the opt-out option is the one that burns the most
    man-hours, mostly of unpaid volunteers. I wonder if it was
    underappreciated when chosing this way.

    Is there a way to get assistance to manage the progressive loss of i386 compatibility upstream, in a way that will consume less time than
    changing 500 packages and filling 500 removal bugs by hand?

    Have a nice day,

    Charles

    --
    Charles Plessy Nagahama, Yomitan, Okinawa, Japan
    Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from home https://framapiaf.org/@charles_plessy
    - You do not have my permission to use this email to train an AI -

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco d'Itri@21:1/5 to Charles Plessy on Mon Oct 14 15:40:01 2024
    On Oct 14, Charles Plessy <plessy@debian.org> wrote:

    The package names starts with r-cran. Upstream, they are tested against amd64 and Silicon only. If you look at the health of the packages and
    the team, it is not good. Well it is as good as many pieces of the free software ecocystem: crumbling under the weight.
    Make the main R package, or another key dependency, build-depend on 64
    bit support, ask for removal of the existing dependencies and you will
    not have to do anything else in the future.

    --
    ciao,
    Marco

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

    iHUEABYIAB0WIQQnKUXNg20437dCfobLPsM64d7XgQUCZw0eEwAKCRDLPsM64d7X gWsJAP9AoCs04TPj1rH/czhU9QV/TV37fyn2TLteRY5AfsQN4QD/U3HhjElMKg0N 3G271OIY1cNzimZzYqtXYPzHv+PDKgE=
    =i64E
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Josefsson@21:1/5 to Sebastiaan Couwenberg on Mon Oct 14 16:00:01 2024
    Sebastiaan Couwenberg <sebastic@xs4all.nl> writes:

    On 10/14/24 2:42 PM, Charles Plessy wrote:
    The package names starts with r-cran.

    Time is better spent on updating the tooling to add
    architecture-is-64-bit to the build dependencies for those packages,
    as well as generating RM bug reports for the partial removals on [i386
    armel armhf].

    Is that the recommended solution for packages that wants to stop
    supporting 32-bit architectures? Some of the *-wrapper packages (e.g., socket-wrapper, see #1069450) became FTBFS after the t64 upload, and I
    haven't seen any solution except to stop supporting those architectures.
    I used the 'not-supported-on [armel armhf]' approach instead of 'architecture-is-64-bit' in my last upload, but there are still reverse dependencies on armel/armhf. Could there be some automatic magic to transitively remove 32-bit binaries of packages where the most recent
    upload of a package uses 'architecture-is-64-bit'? The manual work
    involved to remove packages from the archive leads to people disabling
    self tests on those architectures to avoid build failures, but this just
    masks the problem that the package no longer works reliably on
    armel/armhf. The number of reverse dependencies for me is manageable,
    but the consequences of the i386 decision for Charles seems sub-optimal.

    /Simon

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

    iIoEARYIADIWIQSjzJyHC50xCrrUzy9RcisI/kdFogUCZw0inBQcc2ltb25Aam9z ZWZzc29uLm9yZwAKCRBRcisI/kdFoobsAP0XP38NrwNkh/T96QU0+1yrQH0SmWMK ENQMol1h48h0rAD/SY2iB+MLq0Y2H39fw58WU+q5khlSD7Ew/pf8F+7YPgA=
    =wTM+
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sean Whitton@21:1/5 to All on Thu Oct 17 04:50:01 2024
    Hello,

    I hadn't heard of these architecture-is-64-bit and not-supported-on metapackages(?). Would someone who knows how they are meant to work
    consider submitting a patch for Policy? Thanks.

    --
    Sean Whitton

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

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

    iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmcQevUZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQO/rD/4y37uI+gwEvy0fA8z/DpPU uLNVAXmlw/eWhzpf3dLej/vvjTPMtVTa6WZx/e+lLL+Ea136GdIrbhRYFrA9m2Hv GWqqfKXFEGZt+5crFH1yitBHOWJJ241IJNfIuN/HehGD0tp7TvmyW5NkvHBURguA RuqLug3nBBPbrbwMF3wSeIHQp3EqrM85KWU9z9U95xCab5E3bxX6VIy7cqRV93v8 ZiLOttMebUXbOGkUeHJr6OM6GkcRm9lVESlakRtQT0e3Jf7RmsjFANebM45bVWXH hRkk/wMkCfawXU9zBzcKA+7Oj66kSlLbRvYgEytyFEuz3o8ihNcQrzWpAa0mSVoa dXe/xf70lpM4QUmPeCjYpWG9wyJHPHrCGOFZl9gizJBuVb2g2uxG3eQteVLAmBAW 6qjltrNletvgAWZtxcYhlYOE/fkfEHau3nDTXaNwkVIErZRsgM/tijfPo6rtOpNw Pj3W7ypNlD3GbETH8yyy5G7tVfzdHARFUFfwHxMeojO/fky9go4femWzcmiFUC2C zczl09xGxIDczY8J3iGJzsr4AHTiySqcxsUYpHdd2ylQaC7GJv6w/iCyx8H3uo6+ P0wZw+HZGq2AWplnLSvSSwvia2APIRmKzbC80IevOIqoCPjZz6SUGHB2u8YfqnPI FleYkhZqkxEn28ZNQasC9Q=sxl
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usen
  • From Andrey Rakhmatullin@21:1/5 to Sean Whitton on Thu Oct 17 07:50:02 2024
    On Thu, Oct 17, 2024 at 10:48:21AM +0800, Sean Whitton wrote:
    Hello,

    I hadn't heard of these architecture-is-64-bit and not-supported-on metapackages(?). Would someone who knows how they are meant to work
    consider submitting a patch for Policy? Thanks.

    I think they, just like isa-support, are means to circumvent the Policy /
    work around its and dpkg's shortcomings and so I'm not sure if it makes
    sense to document them there, and if so, where exactly.


    --
    WBR, wRAR

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

    iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmcQpEctFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh krIP/2xk5V5kV+rEzYoch7p77AZycboXLYh6oLeodCQtyKbvDUOPBKUVq6BpDbCk gew9Hh36YGpGyX0yO8Ie4zP6y2TzkxJLhbTs+zKlYSLzHtbenR2aD0BfmOITiw8u JhW56kJd65d3wPh5oqGO80/NMM6Jpz+9xYnkwzrS9/5nNFU3uxO5TaE0yaKT8+y0 H5jGXRo6QOrrfj90nzJ0fhNMOKp8HzCc1wWiOMT7NDL0eadFbhC4KrDiB6oy6soN oh03RGZ2m9xMNKrm4ua4M3ygDJgflcT5lTeb3eKfibrzq18us8as83PLjcNsLFZE 91PpIBPUvLJuxTM+vPD++NH4UFOuKjfzVmA578pQPxZalulipLdiWwR7ehPKzLR8 6PxGRp62HM1nvE1SQbyLMvDOBK49aiXJrWngD13e4snze8nyh52VAzTlOgUH/H9G hl+mSlAu7x1c22JUGquY9sOyilokNXRYh80eB6QgP7CKBBkD0Px/0NIfl1co9+Cv dzDEkfCmZT77mA3k+Nvx1wIYFm7M8WzqWkgf541bl1wpHerzSERBAg1mXLlojmnw NSsjC7uikh5jStIR/qo/wknAYuRgom3SlZ84XikQ6qBqfKnMjpojNnFgslaFemwI e+McT7H7pVpn1mt7annuTGupoh6SackaXTTm2Vnsdbnu5CyJ
    =PK6d
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrey Rakhmatullin@21:1/5 to Paul Gevers on Thu Oct 17 10:50:01 2024
    On Thu, Oct 17, 2024 at 10:35:01AM +0200, Paul Gevers wrote:
    I hadn't heard of these architecture-is-64-bit and not-supported-on metapackages(?). Would someone who knows how they are meant to work consider submitting a patch for Policy? Thanks.

    I think they, just like isa-support, are means to circumvent the Policy / work around its and dpkg's shortcomings and so I'm not sure if it makes sense to document them there, and if so, where exactly.

    I don't agree that architecture-is-64-bit is in the same group of circumventing Policy. While isa-support prevents installation by failing during install (IIRC) and is a hack to prevent baseline violation during execution of binaries, architecture-is-64-bit is a *build* dependency and prevents building on architectures where the package isn't supported.

    Right, I agree.

    I haven't heard how not-supported-on works and can't quickly find
    references.

    It's a package that doesn't exist.
    `B-D: not-supported-on [armel armhf]` will get you BD-Uninstallable on
    armel and armhf: https://buildd.debian.org/status/package.php?p=socket-wrapper


    --
    WBR, wRAR

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

    iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmcQzvAtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh aokP/1svdjM1PIJxDArMQcx0p1G9RiJfwVmLS9xwCPELkMwTtRHo036s2b/mewzn tzpnRxUXTlAykWnyTfTxivel3qVIlzNuVML5nKrkn/hbpTfQzMOi5xdcWhUldFYl SvpzVn6mZF890P1JVc9WgS2qz3MLcJYWO8zQ0DP8NMx/bIfLvTSRQ7jqd9WLJich iwpQDiI1x4dWoM0Z7oYj3NuD63aW8lf4AQlocNtUj6nbyJhQ7U4hM2HbTctXDPYo yMjtNPhtX1aEP/RJQVrjjgs0x9d5pwXTmRpw/AB8Ca+zp6OOVFU31faQPzF22TbH rekJ9do3MjNVK5gLOhmP2fW+QGVDuIjQfi3PTau7Eu4uLpeHWz6lDjYz355y+hDr xREQgTMP8ZiiUGKIKve7o7q+1nc/jxdZ+6ivneEHsg07X3vhW5HaQLlfpcI22S3i m4eMd1MSlS/lOj+Kx7yESFUnQ5t8L7/rAo2XT/pDXBKlfjZze1H27q5Zggx5XAXs zv0cBCSo6xSFLKFIzgPdVf+BFaDVoEc8lP4zAiIewozccGfEOATyELnIwmIP9AlU oC4Y0TuUM/cvrJKGamcZ2yz+aW7DE20C1YI06C64rPtjdWnzh0B2lvc4ZdOPEkr9 bxURUqY/6Xn1mYu8T9FXeuTHJdZ6CUkg4FjeoQ0AlYg2qh3L
    =LahF
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Gevers@21:1/5 to All on Thu Oct 17 10:40:02 2024
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------vah7fk9hXWTVUY3hO2d2kzpT
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

    SGksDQoNCk9uIDE3LTEwLTIwMjQgMDc6NDQsIEFuZHJleSBSYWtobWF0dWxsaW4gd3JvdGU6 DQo+IE9uIFRodSwgT2N0IDE3LCAyMDI0IGF0IDEwOjQ4OjIxQU0gKzA4MDAsIFNlYW4gV2hp dHRvbiB3cm90ZToNCj4+IEhlbGxvLA0KPj4NCj4+IEkgaGFkbid0IGhlYXJkIG9mIHRoZXNl IGFyY2hpdGVjdHVyZS1pcy02NC1iaXQgYW5kIG5vdC1zdXBwb3J0ZWQtb24NCj4+IG1ldGFw YWNrYWdlcyg/KS4gIFdvdWxkIHNvbWVvbmUgd2hvIGtub3dzIGhvdyB0aGV5IGFyZSBtZWFu dCB0byB3b3JrDQo+PiBjb25zaWRlciBzdWJtaXR0aW5nIGEgcGF0Y2ggZm9yIFBvbGljeT8g IFRoYW5rcy4NCj4gDQo+IEkgdGhpbmsgdGhleSwganVzdCBsaWtlIGlzYS1zdXBwb3J0LCBh cmUgbWVhbnMgdG8gY2lyY3VtdmVudCB0aGUgUG9saWN5IC8NCj4gd29yayBhcm91bmQgaXRz IGFuZCBkcGtnJ3Mgc2hvcnRjb21pbmdzIGFuZCBzbyBJJ20gbm90IHN1cmUgaWYgaXQgbWFr ZXMNCj4gc2Vuc2UgdG8gZG9jdW1lbnQgdGhlbSB0aGVyZSwgYW5kIGlmIHNvLCB3aGVyZSBl eGFjdGx5Lg0KDQpJIGRvbid0IGFncmVlIHRoYXQgYXJjaGl0ZWN0dXJlLWlzLTY0LWJpdCBp cyBpbiB0aGUgc2FtZSBncm91cCBvZiANCmNpcmN1bXZlbnRpbmcgUG9saWN5LiBXaGlsZSBp c2Etc3VwcG9ydCBwcmV2ZW50cyBpbnN0YWxsYXRpb24gYnkgZmFpbGluZyANCmR1cmluZyBp bnN0YWxsIChJSVJDKSBhbmQgaXMgYSBoYWNrIHRvIHByZXZlbnQgYmFzZWxpbmUgdmlvbGF0 aW9uIGR1cmluZyANCmV4ZWN1dGlvbiBvZiBiaW5hcmllcywgYXJjaGl0ZWN0dXJlLWlzLTY0 LWJpdCBpcyBhICpidWlsZCogZGVwZW5kZW5jeSANCmFuZCBwcmV2ZW50cyBidWlsZGluZyBv biBhcmNoaXRlY3R1cmVzIHdoZXJlIHRoZSBwYWNrYWdlIGlzbid0IA0Kc3VwcG9ydGVkLiBU aGlzIGlzIHZlcnkgc2ltaWxhciB0byB0aGUgZHBrZyBBcmNoaXRlY3R1cmUgZmllbGQsIGJ1 dCB0aGVuIA0Kd2l0aG91dCB0aGUgbmVlZCB0byBzcGVsbCBpdCBvdXQgYW5kIGZ1dHVyZSBw cm9vZiAoYnV0IHllcywgYSBiaXQgb2YgYSANCndvcmsgYXJvdW5kIG9mIGRwa2cgc2hvcnRj b21pbmdzKS4NCg0KSW4gbXkgb3BpbmlvbiAob25seSB3aXRoIGhhbGYgbXkgUmVsZWFzZSBU ZWFtIGhhdCBvbikgDQphcmNoaXRlY3R1cmUtaXMtNjQtYml0IGFzIGEgKmJ1aWxkKiBkZXBl bmRlbmN5IGlzIGZpbmUsIHdoaWxlIEknbSBvZiB0aGUgDQpvcGluaW9uIHRoYXQgaXNhLXN1 cHBvcnQgaXMgYmFzaWNhbGx5IHdyb25nLg0KDQpJIGhhdmVuJ3QgaGVhcmQgaG93IG5vdC1z dXBwb3J0ZWQtb24gd29ya3MgYW5kIGNhbid0IHF1aWNrbHkgZmluZCANCnJlZmVyZW5jZXMu DQoNClBhdWwNCg0K

    --------------vah7fk9hXWTVUY3hO2d2kzpT--

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

    wsB5BAABCAAjFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAmcQzDUFAwAAAAAACgkQnFyZ6wW9dQpb AQgAoTk6374xf7j5IXYxOgFpf+5I/LvxBMe6a2M4SajRRyCXi+c4T5tGXY9pdHD7MljTWs+SNIbK sGMVOoLcUK3tivTYDe5HlioJhbT8pjvCEjqmUrpD+MgvGlwAMWN5QuBbbKJ8opCaZYe4TI9nJCr8 9ROxsHyaGo8uvZeqvYxE01lAP1wuJNIOgR8xLjFwlcnPAnLlnl3LgEKaXaH6i7NLoDD1956m86HD Ejq7HnPsy5l6v83kLwogFAr2FKqb9gNR0zGR5l3b7DTk4oT4mfL0rnytpHUC4eqinZzUSkHytGp1 mvF78ubGPYfu0Qz/sj6BEZqqqbpXg/g8jYVY7lwq2w==
    =sJeW
    -----END PGP SIGNATURE-----

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