This is an OpenPGP/MIME signed message (RFC 4880 and 3156)

Le 2025-01-02 14:04, Helge Deller a écrit :

Package: hdf5
Version: 1.14.5+repack-2
Tags: ftbfs
Usertags: hppa

The fortran test is the only one which fails on hppa: https://buildd.debian.org/status/fetch.php?pkg=hdf5&arch=hppa&ver=1.14.5%2Brepack-2&stamp=1735623616&raw=0

Testing object functions
PASSED
h5ovisit_f 1 FAILED
h5ovisit_f 1a FAILED
h5ovisit_f 2 FAILED
h5ovisit_f 2a FAILED
h5ovisit_by_name_f 1 FAILED
h5ovisit_by_name_f 1a FAILED
Testing object visiting functions
*FAILED*

Which ones exactly can be seen with this patch:

[skipped]

I tried to debug this, but I'm lacking too much fortran or hdf
knowledge.
It seems the gmtime() function is involved.
Could it be caused by the fact that time_t is now 64bit on hppa.
Note: hppa is a big-endian 32-bit userspace platform.

Same failure on powerpc which is big-endian 32-bit as well.

Best,
_g.

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

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAmd3E54ACgkQ7+hsbH/+ z4OoDQgAgxc7SRs7kPtmrN+f9Los3/fQirevx4epU7bgrVgYoea0k1rXApzO1dn+ BtEanj6e01Ce2clux4XVpJ8RATfIZ9uI6yviLrW3zrncyPeKKc2l72OKfVGw4l9U BbbfKkCE9oaaULHIqpCwLu0TpbjQ/PAAuQ5HRa02YgzdBwpqitGwx7m+HTa/+ZZq UuqJtAvN4SKglgLgLuJQVAsPwQfErGteqcUnhHBqAFirOjsaaZxQRmI3dfC/s/BR O9AgdXp/eSu8PWROhOwYxnd1yXk3HL1h5C6ADr2sTX4F+jBRhlbkrRzBt8J2rEFh t9uu8EwN+ZL+sY6XD5zYcGR+XfDWsw==
=fXTa
-----END PGP SIGNATURE-----

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

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)

--=_df9a4c5120811d79c50052d637fd364e
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8;
format=flowed

Le 2025-01-02 23:30, pini@debian.org a écrit :

Le 2025-01-02 14:04, Helge Deller a écrit :

Package: hdf5
Version: 1.14.5+repack-2
Tags: ftbfs
Usertags: hppa

The fortran test is the only one which fails on hppa:
https://buildd.debian.org/status/fetch.php?pkg=hdf5&arch=hppa&ver=1.14.5%2Brepack-2&stamp=1735623616&raw=0

Testing object functions
PASSED
h5ovisit_f 1 FAILED
h5ovisit_f 1a FAILED
h5ovisit_f 2 FAILED
h5ovisit_f 2a FAILED
h5ovisit_by_name_f 1 FAILED
h5ovisit_by_name_f 1a FAILED
Testing object visiting functions
*FAILED*

Which ones exactly can be seen with this patch:

[skipped]

I tried to debug this, but I'm lacking too much fortran or hdf
knowledge.
It seems the gmtime() function is involved.
Could it be caused by the fact that time_t is now 64bit on hppa.
Note: hppa is a big-endian 32-bit userspace platform.

Same failure on powerpc which is big-endian 32-bit as well.

You were right about the gmtime() function being involved. It appears
that on powerpc and hppa it returns 01/01/1970.

I've set up a reproducer (attached).

On powerpc / hppa:

$ gfortran -g -o test_gmtime test_gmtime.F90
$ ./test_gmtime
time8: 1735915109
Year: 1970
Month: 1
Day: 1
Hour: 0
Minute: 0
Second: 0

On amd64:

$ gfortran -g -o test_gmtime test_gmtime.F90
0 ;) pini@pinibrem14:~/tmp/h5gmtime
$ ./test_gmtime
time8: 1735915041
Year: 2025
Month: 1
Day: 3
Hour: 14
Minute: 37
Second: 21

I don't know how to solve this yet.

Any chance you could test it on bookworm, to check if this could be
related to the 64-bit time_t transition?

Best,
--=_df9a4c5120811d79c50052d637fd364e
Content-Transfer-Encoding: base64
Content-Type: text/plain;
name=test_gmtime.F90
Content-Disposition: attachment;
filename=test_gmtime.F90;
size=1803

bW9kdWxlIHRpbWVfbW9kdWxlCiAgdXNlLCBpbnRyaW5zaWMgOjogaXNvX2NfYmluZGluZwogIGlt cGxpY2l0IG5vbmUKCiAgdHlwZSA6OiB0bV90eXBlCiAgICBpbnRlZ2VyKGNfaW50KSA6OiB0bV9z ZWMgICAhIHNlY29uZHMgYWZ0ZXIgdGhlIG1pbnV0ZSBbMC02MF0KICAgIGludGVnZXIoY19pbnQp IDo6IHRtX21pbiAgICEgbWludXRlcyBhZnRlciB0aGUgaG91ciBbMC01OV0KICAgIGludGVnZXIo Y19pbnQpIDo6IHRtX2hvdXIgICEgaG91cnMgc2luY2UgbWlkbmlnaHQgWzAtMjNdCiAgICBpbnRl Z2VyKGNfaW50KSA6OiB0bV9tZGF5ICAhIGRheSBvZiB0aGUgbW9udGggWzEtMzFdCiAgICBpbnRl Z2VyKGNfaW50KSA6OiB0bV9tb24gICAhIG1vbnRocyBzaW5jZSBKYW51YXJ5IFswLTExXQogICAg aW50ZWdlcihjX2ludCkgOjogdG1feWVhciAgISB5ZWFycyBzaW5jZSAxOTAwCiAgICBpbnRlZ2Vy KGNfaW50KSA6OiB0bV93ZGF5ICAhIGRheXMgc2luY2UgU3VuZGF5IFswLTZdCiAgICBpbnRlZ2Vy KGNfaW50KSA6OiB0bV95ZGF5ICAhIGRheXMgc2luY2UgSmFudWFyeSAxIFswLTM2NV0KICAgIGlu dGVnZXIoY19pbnQpIDo6IHRtX2lzZHN0ICEgRGF5bGlnaHQgU2F2aW5nIFRpbWUgZmxhZwogIGVu ZCB0eXBlIHRtX3R5cGUKCiAgSU5URVJGQUNFCiAgICBGVU5DVElPTiBnbXRpbWVfYyhzdGR0aW1l X3QpIEJJTkQoQywgTkFNRT0nZ210aW1lJykKICAgICAgSU1QT1JUIDo6IENfUFRSCiAgICAgIElN UExJQ0lUIE5PTkUKICAgICAgSU5URUdFUig4KSA6OiBzdGR0aW1lX3QKICAgICAgVFlQRShDX1BU UikgOjogZ210aW1lX2MKICAgIEVORCBGVU5DVElPTiBnbXRpbWVfYwogIEVORCBJTlRFUkZBQ0UK CmNvbnRhaW5zCgogIHN1YnJvdXRpbmUgZ2V0X2dtdGltZSh0aW1lLCB0bSkKICAgIHVzZSwgaW50 cmluc2ljIDo6IGlzb19jX2JpbmRpbmcKICAgIGltcGxpY2l0IG5vbmUKICAgIGludGVnZXIoOCks IGludGVudChpbikgOjogdGltZQogICAgdHlwZSh0bV90eXBlKSwgaW50ZW50KG91dCkgOjogdG0K ICAgIHR5cGUoY19wdHIpIDo6IHRtX3B0cgogICAgdHlwZSh0bV90eXBlKSwgcG9pbnRlciA6OiB0 bV9wCgogICAgdG1fcHRyID0gZ210aW1lX2ModGltZSkKICAgIGlmIChjX2Fzc29jaWF0ZWQodG1f cHRyKSkgdGhlbgogICAgICBjYWxsIGNfZl9wb2ludGVyKHRtX3B0ciwgdG1fcCkKICAgICAgdG0g PSB0bV9wCiAgICBlbHNlCiAgICAgIHByaW50ICosICJFcnJvcjogZ210aW1lX2MoKSByZXR1cm5l ZCBhIG51bGwgcG9pbnRlci4iCiAgICBlbmQgaWYKICBlbmQgc3Vicm91dGluZSBnZXRfZ210aW1l CgplbmQgbW9kdWxlIHRpbWVfbW9kdWxlCgpwcm9ncmFtIHRlc3RfZ210aW1lCiAgdXNlIHRpbWVf bW9kdWxlCiAgdXNlLCBpbnRyaW5zaWMgOjogaXNvX2NfYmluZGluZwogIGltcGxpY2l0IG5vbmUK ICBpbnRlZ2VyKDgpIDo6IGN1cnJlbnRfdGltZQogIHR5cGUodG1fdHlwZSkgOjogdG0KCiAgY3Vy cmVudF90aW1lID0gdGltZTgoKQogIGNhbGwgZ2V0X2dtdGltZShjdXJyZW50X3RpbWUsIHRtKQoK ICBwcmludCAqLCAidGltZTg6ICIsIGN1cnJlbnRfdGltZQogIHByaW50ICosICJZZWFyOiAiLCB0 bSV0bV95ZWFyICsgMTkwMAogIHByaW50ICosICJNb250aDogIiwgdG0ldG1fbW9uICsgMQogIHBy aW50ICosICJEYXk6ICIsIHRtJXRtX21kYXkKICBwcmludCAqLCAiSG91cjogIiwgdG0ldG1faG91 cgogIHByaW50ICosICJNaW51dGU6ICIsIHRtJXRtX21pbgogIHByaW50ICosICJTZWNvbmQ6ICIs IHRtJXRtX3NlYwoKZW5kIHByb2dyYW0gdGVzdF9nbXRpbWUK --=_df9a4c5120811d79c50052d637fd364e--


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

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAmd3+n4ACgkQ7+hsbH/+ z4PW4ggAqeTX93b66/RlJMAbBSMz/S2Ku/IHQcopvah4v+9ub7+oZSerHH9t/KcO FJgfDz93Q3KhA9T4xKVlBnOZko4o84WrPBd7kSOuIkVgH/xS2eCtzD/MEJCl85pQ IgKWafQBTnLkF+ADrDT2hYdIxOdfaVQsfB4Y2weShjKtUvx469qsWWthBDAPI3gd PKhMKChxARZ7SKXTcYYZoOjqT6w18WYnjip2iX+qdzFaMzK3dAp6NmY+D+pwFwv1 UmQuYs0ZmcE3vit9AeOWJ0uT6bV/0UPTNYzsUsdxh+Q1U9lzfr6zOSBVgNq7q+19 vVat7ehi0PU1kahBPg6v3lIYTVTexw==
=YNZt
-----END PGP SIGNATURE-----

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

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)

Le 2025-01-03 17:43, Helge Deller a écrit :

On 1/3/25 15:55, pini@debian.org wrote:

You were right about the gmtime() function being involved. It
appears that on powerpc and hppa it returns 01/01/1970. I've set up a
reproducer (attached).

That's what I needed.
Thanks!

On powerpc / hppa:

$ gfortran -g -o test_gmtime test_gmtime.F90
$ ./test_gmtime
 time8:            1735915109
 Year:         1970
 Month:            1
 Day:            1
 Hour:            0
 Minute:            0
 Second:            0

On amd64:

$ gfortran -g -o test_gmtime test_gmtime.F90
0 ;) pini@pinibrem14:~/tmp/h5gmtime
$ ./test_gmtime
 time8:            1735915041
 Year:         2025
 Month:            1
 Day:            3
 Hour:           14
 Minute:           37
 Second:           21

I don't know how to solve this yet.

Ok, I know how to fix it:
In your fortran example, replace
FUNCTION gmtime_c(stdtime_t) BIND(C, NAME='gmtime')
by:
FUNCTION gmtime_c(stdtime_t) BIND(C, NAME='__gmtime64')

On 32-bit platforms, glibc provides "gmtime" for 32-bit time_t,
and __gmtime64 for 64-bit time_t. At compile time depending
on defines, one or the other is used.

Is it possible to detect during config time, if that function
is exported by glibc, and then use it if it's available?

I'm not sure that would be the correct solution. I think there is now an inconsistency between gcc and gfortran on hppa and powerpc, the former
using __gmtime64 as the default for gmtime, and the latter sticking to
its legacy 32-bit implementation.

This problem doesn't exist on litte-endian 32-bit architectures.

Best,
_g.

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

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAmd4JZIACgkQ7+hsbH/+ z4MOgAgAnsFo4p6Xxg1FTDukphoHSGGK65A+wFAOpgucfkVIIL133NLsD52wqwqP HQ0AJiF7E2DAo3pDhaEH+scoSVNlmdHv4E7SVa+4RoLPU24bXYs0zA65oWnSt3IZ yPsNeQSVcBQow3SR9waArIkmrJnXajsvfaojxjraP459vi16W6SkBxCRJ6lshBS5 XbsUexWPvePZ9ewqxMt6FNAMSnrs3rvksxuN7iY2S+tfCgmdk2u1VkP3Rsb5dIWR JTTXaSuPsskqIAIU9eTzxUEVfU+8YrdGN1xqabtgU6ypTtivWQgZl/NK9LuZui/G RcAkyaAuT4E0VK7pGLVboCcBz7e/rQ==
=zqVv
-----END PGP SIGNATURE-----

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

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)

--=_bb5e52ed4e19b6452b58e1b5afcdfecd
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8;
format=flowed

Le 2025-01-03 19:23, Helge Deller a écrit :

On 1/3/25 18:59, pini@debian.org wrote:

Le 2025-01-03 17:43, Helge Deller a écrit :

On 1/3/25 15:55, pini@debian.org wrote:

You were right about the gmtime() function being involved. It
appears that on powerpc and hppa it returns 01/01/1970. I've set up
a reproducer (attached).

That's what I needed.
Thanks!

On powerpc / hppa:

$ gfortran -g -o test_gmtime test_gmtime.F90
$ ./test_gmtime
  time8:            1735915109
  Year:         1970
  Month:            1
  Day:            1
  Hour:            0
  Minute:            0
  Second:            0

On amd64:

$ gfortran -g -o test_gmtime test_gmtime.F90
0 ;) pini@pinibrem14:~/tmp/h5gmtime
$ ./test_gmtime
  time8:            1735915041
  Year:         2025
  Month:            1
  Day:            3
  Hour:           14
  Minute:           37
  Second:           21

I don't know how to solve this yet.

Ok, I know how to fix it:
In your fortran example, replace
    FUNCTION gmtime_c(stdtime_t) BIND(C, NAME='gmtime')
by:
    FUNCTION gmtime_c(stdtime_t) BIND(C, NAME='__gmtime64')

On 32-bit platforms, glibc provides "gmtime" for 32-bit time_t,
and __gmtime64 for 64-bit time_t. At compile time depending
on defines, one or the other is used.

Is it possible to detect during config time, if that function
is exported by glibc, and then use it if it's available?

I'm not sure that would be the correct solution. I think there is
now an inconsistency between gcc and gfortran on hppa and powerpc,
the former using __gmtime64 as the default for gmtime, and the
latter sticking to its legacy 32-bit implementation.

No. Both use the 64-bit implementation on debian, since debian
defines _TIME_BITS=64 on all 32-bit platforms (beside x86 due to compatibility).

The rule should be:

if H5_SIZEOF_TIME_T == 8
use __gmtime64 if glibc provides it, else
use gmtime which is the default.
else
use gmtime

This works for all: 32- and 64-bit, big- and little-endian.

This problem doesn't exist on litte-endian 32-bit architectures.

Yes, it does.
The only difference is, that on little-endian the lower 32-bits of
the time_t value is stored in the first 4 bytes (and thus have the
correct
value), while on big endian the upper 32bits (which are zero) are
stored
in the lower 4 bytes - which is why you get here the wrong date.

I came up with the attached patch.

Best,
_g.

--=_bb5e52ed4e19b6452b58e1b5afcdfecd
Content-Transfer-Encoding: base64
Content-Type: text/x-diff;
name=hdf5-1091911.debdiff
Content-Disposition: attachment;
filename=hdf5-1091911.debdiff;
size=2756

ZGlmZiAtTnJ1IGhkZjUtMS4xNC41K3JlcGFjay9kZWJpYW4vY2hhbmdlbG9nIGhkZjUtMS4xNC41 K3JlcGFjay9kZWJpYW4vY2hhbmdlbG9nCi0tLSBoZGY1LTEuMTQuNStyZXBhY2svZGViaWFuL2No YW5nZWxvZwkyMDI0LTEyLTMwIDIwOjE4OjU2LjAwMDAwMDAwMCArMDEwMAorKysgaGRmNS0xLjE0 LjUrcmVwYWNrL2RlYmlhbi9jaGFuZ2Vsb2cJMjAyNS0wMS0wMyAxODowMzo1My4wMDAwMDAwMDAg KzAxMDAKQEAgLTEsMyArMSwxMCBAQAoraGRmNSAoMS4xNC41K3JlcGFjay0zKSBVTlJFTEVBU0VE OyB1cmdlbmN5PW1lZGl1bQorCisgICogTmV3IHBhdGNoIGZvcnRyYW5fZ210aW1lNjQucGF0Y2g6 IGZpeCBmb3J0cmFuIGdtdGltZSByZWxhdGVkCisgICAgZmFpbHVyZXMgb24gYmlnLWVuZGlhbiAz Mi1iaXQgYXJjaGl0ZWN0dXJlcyAoY2xvc2VzOiAjMTA5MTkxMSkKKworIC0tIEdpbGxlcyBGaWxp cHBpbmkgPHBpbmlAZGViaWFuLm9yZz4gIEZyaSwgMDMgSmFuIDIwMjUgMTg6MDM6NTMgKzAxMDAK KwogaGRmNSAoMS4xNC41K3JlcGFjay0yKSB1bnN0YWJsZTsgdXJnZW5jeT1tZWRpdW0KIAogICAq IEFja25vbGVkZ2UgcHJldmlvdXNseSBmaXhlZCBDVkU6CmRpZmYgLU5ydSBoZGY1LTEuMTQuNSty ZXBhY2svZGViaWFuL3BhdGNoZXMvZm9ydHJhbl9nbXRpbWU2NC5wYXRjaCBoZGY1LTEuMTQuNSty ZXBhY2svZGViaWFuL3BhdGNoZXMvZm9ydHJhbl9nbXRpbWU2NC5wYXRjaAotLS0gaGRmNS0xLjE0 LjUrcmVwYWNrL2RlYmlhbi9wYXRjaGVzL2ZvcnRyYW5fZ210aW1lNjQucGF0Y2gJMTk3MC0wMS0w MSAwMTowMDowMC4wMDAwMDAwMDAgKzAxMDAKKysrIGhkZjUtMS4xNC41K3JlcGFjay9kZWJpYW4v cGF0Y2hlcy9mb3J0cmFuX2dtdGltZTY0LnBhdGNoCTIwMjUtMDEtMDMgMTg6MDM6NTMuMDAwMDAw MDAwICswMTAwCkBAIC0wLDAgKzEsMjQgQEAKK0luZGV4OiBoZGY1L2ZvcnRyYW4vc3JjL0g1X2Zm LkY5MAorPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQorLS0tIGhkZjUub3JpZy9mb3J0cmFuL3NyYy9INV9mZi5GOTAKKysr KyBoZGY1L2ZvcnRyYW4vc3JjL0g1X2ZmLkY5MAorQEAgLTQ2LDYgKzQ2LDcgQEAKKyAhCisgCisg I2luY2x1ZGUgPEg1Y29uZmlnX2YuaW5jPgorKyNpbmNsdWRlIDxmZWF0dXJlcy10aW1lNjQuaD4K KyAKKyBNT0RVTEUgSDVMSUIKKyAKK0BAIC0xMDY0LDcgKzEwNjUsMTEgQEAgQ09OVEFJTlMKKyAg ICAgSU5URUdFUihDX0lOVCksIERJTUVOU0lPTig6KSwgUE9JTlRFUiA6OiBjX3RpbWUKKyAKKyAg ICAgSU5URVJGQUNFCisrI2lmbmRlZiBfX1VTRV9USU1FX0JJVFM2NAorICAgICAgICBGVU5DVElP TiBnbXRpbWUoc3RkdGltZV90KSBCSU5EKEMsIE5BTUU9J2dtdGltZScpCisrI2Vsc2UKKysgICAg ICAgRlVOQ1RJT04gZ210aW1lKHN0ZHRpbWVfdCkgQklORChDLCBOQU1FPSdfX2dtdGltZTY0JykK KysjZW5kaWYKKyAgICAgICAgICBJTVBPUlQgOjogVElNRV9ULCBDX1BUUgorICAgICAgICAgIElN UExJQ0lUIE5PTkUKKyAgICAgICAgICBJTlRFR0VSKEtJTkQ9VElNRV9UKSA6OiBzdGR0aW1lX3QK ZGlmZiAtTnJ1IGhkZjUtMS4xNC41K3JlcGFjay9kZWJpYW4vcGF0Y2hlcy9zZXJpZXMgaGRmNS0x LjE0LjUrcmVwYWNrL2RlYmlhbi9wYXRjaGVzL3NlcmllcwotLS0gaGRmNS0xLjE0LjUrcmVwYWNr L2RlYmlhbi9wYXRjaGVzL3NlcmllcwkyMDI0LTEyLTMwIDE3OjQwOjIxLjAwMDAwMDAwMCArMDEw MAorKysgaGRmNS0xLjE0LjUrcmVwYWNrL2RlYmlhbi9wYXRjaGVzL3NlcmllcwkyMDI1LTAxLTAz IDE4OjAwOjM3LjAwMDAwMDAwMCArMDEwMApAQCAtNywzICs3LDQgQEAKIGphdmFfdXNlLXN5c3Rl bS1qYXJzLnBhdGNoCiBmbG9hdDEyOC5wYXRjaAogY2hlYXQtZm9ydHJhbmxpYl90ZXN0LnBhdGNo Citmb3J0cmFuX2dtdGltZTY0LnBhdGNoCmRpZmYgLU5ydSBoZGY1LTEuMTQuNStyZXBhY2svZGVi aWFuL3J1bGVzIGhkZjUtMS4xNC41K3JlcGFjay9kZWJpYW4vcnVsZXMKLS0tIGhkZjUtMS4xNC41 K3JlcGFjay9kZWJpYW4vcnVsZXMJMjAyNC0xMi0zMCAyMDoxODo0OS4wMDAwMDAwMDAgKzAxMDAK KysrIGhkZjUtMS4xNC41K3JlcGFjay9kZWJpYW4vcnVsZXMJMjAyNS0wMS0wMyAxODowMzo1My4w MDAwMDAwMDAgKzAxMDAKQEAgLTE1Nyw2ICsxNTcsMTEgQEAKIAogZXhwb3J0IERFQl9DRkxBR1Nf TUFJTlRfU1RSSVAgPSAtV2Vycm9yPWZvcm1hdC1zZWN1cml0eSAtV2Vycm9yPWltcGxpY2l0LWZ1 bmN0aW9uLWRlY2xhcmF0aW9uCiBleHBvcnQgREVCX0NYWEZMQUdTX01BSU5UX1NUUklQID0gLVdl cnJvcj1mb3JtYXQtc2VjdXJpdHkKKyMgRml4IGZvciAjMTA5MTkxMSBhbG9uZyB3aXRoIHBhdGNo IGZvcnRyYW5fZ210aW1lNjQucGF0Y2gKKyMgVGhlc2UgZmxhZ3Mgc2hvdWxkIGJlIGRlZmluZWQg b25seSB3aGVuIGRwa2ctYnVpbGRmbGFncyBzZXRzIC1EX1RJTUVfQklUUz02NAoraWZuZXEgKCwk KGZpbHRlciAtRF9USU1FX0JJVFM9NjQsJChzaGVsbCBkcGtnLWJ1aWxkZmxhZ3MgLS1nZXQgQ1BQ RkxBR1MpKSkKK2V4cG9ydCBERUJfRkNGTEFHU19NQUlOVF9BUFBFTkQgPSAtRF9GSUxFX09GRlNF VF9CSVRTPTY0IC1EX1RJTUVfQklUUz02NAorZW5kaWYKIAogIyBDb21wb3NlIHRoZSBwYWNrYWdl cycgbmFtZSBmbGF2b3IgcGFydCBmcm9tICQoZmxhdm9yKQogZmxhdm9ycGtnID0gJChzdWJzdCAt c2VyaWFsLCwtJChmbGF2b3IpKQo=
--=_bb5e52ed4e19b6452b58e1b5afcdfecd--


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

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAmd4Q2kACgkQ7+hsbH/+ z4O3xQgApafhTpBUk+FfsRhjT7fodWxWYGTVyxR3upH4N9RGiIXHd1WzJzLmOIHa YBUdbCPMtnEOspOIwAyscU0QRjSWDxtAs4xttYpC6ZAIpLI2Qat+3oz7BqasBNAi eROMlY992cBuBYqbeeCOhg0L+4OJb8MdLrvpBn8JF+qW7bjHPykWykCn+F77kybm eS2I6ofYXj7eqhnaO17jYXd2XnHEVFDCgnr3Nsp8abA4p7IxbER3pC9tKr0viQ7g VcEbWRjACDEPEzgWSHvh20iE1qvJ5XWWBfgAUiOfISoo5WvcTR9L6vg7iz/ivmAv ojUW/6Y4BYoF+6o3YhTLf5+SYoynaw==
=q20q
-----END PGP SIGNATURE-----

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