Brian Nelson <[EMAIL PROTECTED]> writes: > Steve Langasek <[EMAIL PROTECTED]> writes: > >> On Tue, Jul 19, 2005 at 11:52:51PM -0700, Brian Nelson wrote: >>> Reintroducing the libaspell15 could cause problems with >> /usr/bin/aspell, >>> since it actually goes outside the C API of libaspell and uses C++ >>> linkage to some symbols. I "fixed" this bug (#307481) by making >>> aspell-bin (or now just aspell) depend on the Source-Version of >>> libaspell. >> >>> However, that fix is not in the stable package of aspell. In stable, >>> aspell-bin just depends on libaspell15 (>= 0.60), so a partial upgrade >>> of just libaspell15 would break aspell-bin. I suppose I could make >> the >>> new libaspell15 conflict with the old aspell-bin, but that's rather >>> clumsy and could make upgrades even more awkward. >> >>> I'm not sure what the best thing to do would be. I'm sort of inclined >>> to just stick with the transitioned libaspell15c2... >> >> Well, using libaspell15c2 will definitely cause some complexity on the >> upgrade path from sarge to etch. I don't know how much having >> libaspell15 >> conflict with aspell-bin (<< $version) would do so. I suspect that it >> would be substantially less since there are only four packages in sarge >> which depend directly on aspell-bin or aspell, vs. 61 packages which >> depend >> on libaspell15 -- at a minimum, the worst-case scenario when conflicting >> with aspell-bin (<< $version) looks substantially better. > > OK, very well then, I'll undo the GCC 4 transition for libaspell15. > > BTW, does anyone familiar with gettext want to send me a patch for RC > bug #316666? Upstream said he plans to make a new release with an > upgrade to gettext 0.14.5 sometime this week, but I haven't heard > anything else from him.
I just run gettextize, aclocal, automake (version 1.7 is needed irrc), autoconf and recompiled. That seemed to have fixed it for me. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]