It appears as if qt is using it's own version of zlib if the zlib USE flag is not set. From 3.3.5 Changelog: Added security patches for zlib: CAN-2005-1849, CAN-2005-2096
Hm. Let's say USE=-zlib is quite uncommon and rate this B2.
KDE team: your position on this, please.
FYI: 3.3.5 is in portage now, as unstable.
Thanks Caleb. Is it a candidate for stable right now ?
(In reply to comment #4) > Thanks Caleb. Is it a candidate for stable right now ? I think not, see bug 106402. I suggest to commit qt-3.3.4-r8, the only difference to -r7 being that it forces "-system-zlib" as a compilation option. qt-3.3.4-r7 was ready to go stable, so qt-3.3.4-r8 could go stable right now.
Back to ebuild status, waiting for a suitable ebuild to mark stable.
#5 works for me.
Yeah it does for me as well if -r8 gets committed.
-r8 is committed, but not yet stable on any arches. I don't see why it can't go stable right away, but I'd like one more opinion on the matter (greg?).
I agree that it can go stable right now. Actually I was going to propose -r7 for stable just before this bug showed up.
OK, let's go then: archs please test and mark 3.3.4-r8 stable Target KEYWORDS="alpha amd64 hppa ia64 mips ppc ppc64 ~ppc-macos sparc x86"
This version also introduces a dep on ~dev-db/qt-unixODBC-3.3.4 which isn't currently stable on amd64 and has an open security bug against it (bug 105719) - advise on this please.
I've committed a patch to the qt-unixodbc ebuild that should fix the RUNPATH problem.
stable on ppc64
sparc stable (with qt-unixODBC-3.3.4-r1).
Stable on hppa, ppc
Looks good - stable on amd64.
Looks ok on alpha.
Stable on x86
Common GLSA with the qt-unixodbc thing ?
Let's do a common GLSA with qt.
with qt-unixodbc of course :-)
GLSA 200509-18 ia64 and mips don't forget to mark stable to benifit from the GLSA.
Stable on mips.