Matthew, Regarding the swig incompatibility, I think you are right. It probably is a matter of poking the right people and waiting.
However, it is technically possible to compile on Debian stable then upload the binary package to unstable (a.k.a. sid). This can - somewhat - bypass the swig issue and get a working PyLucene package in Debian for one architecture, presumably i386. Once the swig issue gets straightened out, the autobuilders will be able to handle the other architectures. I know this sounds yucky, but it's not that uncommon. Usually the way it goes is a package builds on unstable, gets added to Debian, some build dependency gets updated, then the build breaks, and the package gets a FTBFS (fails to build from source) bug, then someone fixes it. Debian has been dealing with this type of problem for a long time with reasonable success. The gcj situation is more serious. No way in hell can we package the gcj runtime inside the PyLucene package. As far as I can tell this is a showstopper, although I'm curious what the gcj package maintainers have to say about the matter. As for things to do, here's the best list I can think of: - find out what the real story is for getting into backports.org - help make sure the right people have the right information. Is Andi in good contact with the Swig authors already? Do they need more detailed bug reports? - I noticed the package is only valid for python-2.4. Most Debian python packages support multiple versions of python. Maybe this is something to work on while other paths are blocked? - See if our counterparts in RedHat, Gentoo, Suse, etc. have made progress on any of these issues. (Unlikely, I suspect otherwise Andi would know about it). Finally, Matthew I'd like to know your estimated attention span as we consider the possibility of putting a semi-broken package into Debian. My comfort zone for [get it fairly good first] vs [put it in then improve it] shifts a little depending on whether you have short term or long term interest. Jeff
