It appears as if qt is using it's own version of zlib if the zlib USE flag is
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 :-)
ia64 and mips don't forget to mark stable to benifit from the GLSA.
Stable on mips.