[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

package system broken by aptitude removing cupsys



I am a long-time Debian user and sysadmin and I'm very frustrated
these days.  There seems no way out of my problem, other than to
re-install the entire OS from scratch and then simply *not* attempt to
replace cupsys, which still doesn't work.  I have fallen into this
"now start all over" trap several times over the past year or so.  It
is really bad, and advice would be welcome.

Once again, I've just installed a new OS (this time, lenny, but the
same problem has occurred repeatedly with etch) using the Sep 2 2007
daily build of netinst.

I don't know how to prevent cupsys from being installed, so, once
again, I've hoped that cupsys and all its gnome-trickery would work
properly.  Unfortunately, it still doesn't, at least insofar as my
microsopic remaining patience with it allows me to determine.

Once again, I've tried to use aptitude to remove cupsys and replace it
with lprng.

Cupsys once again fails to remove itself, failing on the removal of
python-qt3 and/or python-sip4.  Worse, once this failure occurs,
aptitude doesn't work any more. Thereafter, all
installations/de-installations fail with messages that include:

warning: Python C API version mismatch for module time: This Python has API version 1012, module time has version 1013.
warning: Python C API version mismatch for module _locale: This Python has API version 1012, module _locale has version 1013.
warning: Python C API version mismatch for module select: This Python has API version 1012, module select has version 1013.
Traceback (most recent call last):
  File "/usr/bin/pycentral", line 1394, in ?
    main()
  File "/usr/bin/pycentral", line 1388, in main
    rv = action.run(global_options)
  File "/usr/bin/pycentral", line 879, in run
    pkg.read_version_info()
  File "/usr/bin/pycentral", line 544, in read_version_info
    self.version_info = pyversions.parse_versions(self.version_field)
  File "/usr/share/pycentral-data/pyversions.py", line 29, in parse_versions
    import operator
ImportError: /usr/lib/python2.5/lib-dynload/operator.so: undefined symbol: PyInt_FromSsize_t

For months, now, the API mismatch has been the same two version
numbers: 1013 and 1012.

Many weeks ago, thinking that it was a problem with Python 2.5, I
wrote to the maintainer of that package.  No answer.  Anyway, I'm
not sure that it's his problem.

All advice welcome.

-- Steve

Steven R. Newcomb, Consultant
Coolheads Consulting

Co-editor, Topic Maps International Standard (ISO/IEC 13250)
Co-editor, draft Topic Maps -- Reference Model (ISO/IEC 13250-5)

srn@coolheads.com
http://www.coolheads.com

direct: +1 910 363 4032
main:   +1 910 363 4033
fax:    +1 910 454 8461

268 Bonnet Way
Southport, North Carolina 28461 USA

(This communication is not private.  Since the destruction of the 1978
Foreign Intelligence Surveillance Act by the U.S. Congress on August
5, 2007, no electronic communications of innocent citizens can be
hidden from the U.S. government.  Shamefully, our own generation,
acting on fears promoted by fraudulently-elected rogues, has allowed
absolute power (codenamed "unitary Executive") to be usurped by those
very same rogues.  Hail Caesar!)



Reply to: