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]
-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.
==
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 [EMAI
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]
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 PROTECTE
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 PROTECT
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
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 o
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 PROTECT
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 anyon
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
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/
--
12 matches
Mail list logo
