Bugzilla Bug 105695

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.