Bug#320794: please recompile evince against libdjvulibre-dev (= 3.5.14-6)

2005-08-05 Thread Barak Pearlmutter
Sebastien, Could I trouble you to recompile and dupload evince against libdjvulibre1 (= 3.5.14-6) to deal with soname change? Evince is the only package that uses the lib, so that will clear the issue. I'm not sure if the API has changed in a fashion that justifies a chance in soname. Upstream

Bug#320794: please recompile evince against libdjvulibre-dev (= 3.5.14-6)

2005-08-05 Thread Barak Pearlmutter
Problem is what does fix djvulibre mean here? Fix it to generate the old soname, thus losing soname compatibility with upstream? Fix it to generate a different library name, perhaps libdjvulibre15? Fix it by asking upstream to stop changing the soname for no reason? Fix it by convincing anyone

Bug#320794: please recompile evince against libdjvulibre-dev (= 3.5.14-6)

2005-08-05 Thread Barak Pearlmutter
Yes, all true. I will upload a rev which generates libdjvulibre15. When that comes down the pike, please recompile evince against it. --Barak. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL

Bug#320582: libdjvulibre1: soname of library changed

2005-08-14 Thread Barak Pearlmutter
The upload is no problem, I have things fixed already in CVS, and they are mostly trivial anyway. In fact the X library stuff fixed itself. The only thing hold me up is the m68k issue. I have not taken the time to dive in the build system far enough to figure out how to either change -O3 to -O2

Bug#321107: Bug#320582: djvulibre NMU being prepared

2005-08-14 Thread Barak Pearlmutter
PS But on second thought, please go ahead and NMU with that patch. It should clear the issue for now, and shouldn't do any harm. Later I'll fix it right and upload that. And your NMU will allow me to take my time finding the right fix. Which I suppose involves writing an autoconf script to

Bug#321107: Bug#320582: djvulibre NMU being prepared

2005-08-14 Thread Barak Pearlmutter
Um, that patches the script configure without a corresponding patch to configure.ac. But the first is built periodically from the second. I'd rather have a more permanent solution to the problem... --Barak. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED]

Bug#328104: solved itself

2005-10-25 Thread Barak Pearlmutter
this issue seems to have solved itself, in the fullness of time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#319436: FTBFS: Does not declare class before using it

2005-07-22 Thread Barak Pearlmutter
Just to confirm: this is a GCC 4.0 issue, which I have replicated. I will mention it to upstream; I'm sure they will want to be GCC 4.0 clean. -- Barak A. Pearlmutter [EMAIL PROTECTED] Hamilton Institute Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland http://www-bcl.cs.nuim.ie/~barak/ --

Bug#328104: djview in testing depends on libqt3-mt only available in unstable

2005-09-13 Thread Barak Pearlmutter
This isn't djview's fault, is it? I'll wait, and close this bug once libqt3-mt migrates into testing. -- Barak A. Pearlmutter [EMAIL PROTECTED] Hamilton Institute Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland http://www-bcl.cs.nuim.ie/~barak/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED]

Bug#328104: djview in testing depends on libqt3-mt only available in unstable

2005-09-13 Thread Barak Pearlmutter
Sure, but there is an automated system that does the unstable-to-testing migration. Don't know why it failed here. --Barak. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#328104: djview in testing depends on libqt3-mt only available in unstable

2005-09-13 Thread Barak Pearlmutter
Yes, it probably has to do with that. Will look into a transitional package. But although it might solve the multiple libdjvulibre1 vs multiple libdjvulibre15 problem, it probably won't solve this libqt* issue. --Barak. -- To UNSUBSCRIBE, email to

Bug#328597: very old package, should this be removed?

2005-09-16 Thread Barak Pearlmutter
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yes; I think it would be okay to remove oaklisp at this point. (If I ever get around to making the upstream changes it needs to bring it into the 2000s I'll just upload the result as a new package.) --Barak. ==