--=-iR5QrKsFJpa+YacvTW3k Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2003-01-15 at 13:15, R P Herrold wrote: > On 15 Jan 2003, seth vidal wrote: >=20 > > > You don't mention yum version, but in the latest, > > > clientStuff.py at line 173 looks to be uncompressing the > > > header payload of something local, and has an uncaught > > > exception, which triggered the traceback -- [dumping a stack > > > trace is a 'pythonism' default, when there is an uncaught > > > exception, similar to leaging a 'core' file] > >=20 > > he was running 0.9.3 - in the fine print. > > gzip was returning a crc error from a header he downloaded - b/c the > > packages are handled by gzip - only the headers. >=20 > heh -- As the author of the code, you know the codepaths > already -- I was desk tracing, and scoped it out <grin>. >=20 > RFE: Can the exception be caught, and a more helpful error > message to identify the corrupt file (or maybe, emit a > warning, and set a flag to rm and repull the offending file a > time or two [it might be corrupt in the remote archive, so a > limit on repull attempts, and a notation of the problem file > make sense here])? >=20 Yes it can be caught - but I want to know what's causing it :) a crc error from gzip seems all ugly. -sv --=-iR5QrKsFJpa+YacvTW3k Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA+JaXi1Aj3x2mIbMcRAijLAJ46+cHPijHDvvXP2teQCbJ47CsSUwCaAgdt M/ZePZ6vvMSsFSIrwySQLbU= =Q1Iz -----END PGP SIGNATURE----- --=-iR5QrKsFJpa+YacvTW3k--
