[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Pkg-kde-talk] Re: Please allow kdenetwork and kdelibs into Sarge



On May 10, 2005 07:45, Steve Langasek wrote:
> On Mon, May 09, 2005 at 08:32:54AM -0400, Christopher Martin wrote:
> > kdenetwork 4:3.3.2-3, replacing 4:3.3.2-1 in Sarge, fixes a number of
> > bugs, including several that are RC. These packages have been in Sid
> > for some time, but held out due to missing buildds, so they've proven
> > themselves solid. The most recent upload, from late April, contained
> > only packaging changes:
>
> Approved (though still waiting on a sarge upload).

Thanks.

> Going forward, it would be nice if you would check whether uuencoding
> something that's already a diff (and, er, not changing the name of a diff
> just because the date changed), so that changes can be reviewed using
> interdiff alone.  I imagine this is being done here to guard against
> dpkg's failure to use -a when generating diffs, and I suspect it's not
> actually necessary if you've got everything in a diff file *anyway*,
> because the diff header itself ought to mark the file as ascii.

Sorry about the hassle - the kdenetwork uploads were made before the freeze, 
which is when we started thinking in terms of ease-of-readability. As for 
uuencoding, it is, unfortunately, necessary when binary files are 
added/updated in a diff. The use of -a when generating a diff doesn't seem 
to prevent dpkg from choking on it. While for the KDE 3.3 packages all 
branch diffs are uuencoded (more out of tradition than anything else), 
we're being more  selective with the post-Sarge 3.4 branch pulls.

> > As for kdelibs, the sole change between 4:3.3.2-5 and 4:3.3.2-6 is that
> > we added a very small patch (from upstream) to upstream's latest
> > security fix, which caused regressions reading some image files.
> > Definitely worth getting into Sarge, even if the problem doesn't seem
> > to have security implications.
> >
> > 23_kimgio_fix.diff
> > --- kde.orig/kimgio/rgb.cpp
> > +++ kde.patched/kimgio/rgb.cpp
> > @@ -272,7 +272,8 @@ bool SGIImage::readImage(QImage& img)
> >         // sanity ckeck
> >         if (m_rle)
> >                 for (uint o = 0; o < m_numrows; o++)
> > -                       if (m_starttab[o] + m_lengthtab[o] >=
> > m_data.size()) {
> > +                       // do not convert to >=
> > +                       if (m_starttab[o] + m_lengthtab[o] >
> > m_data.size()) {
> >                                 kdDebug(399) << "image corrupt (sanity
> > check failed)" << endl;
> >                                 return false;
> >                         }
>
> The accompanying changelog isn't very enlightening; what filetypes are
> broken, and why?  Can you offer a pointer to discussion of this bug?

Certainly. The security advisory can be found at 
http://www.kde.org/info/security/advisory-20050504-1.txt. In summary, most 
RGB files (an older SGI format, but it's still around) can no longer be 
read. The one-line change (from upstream) we added between -5 and -6 fixes 
this regression.

Cheers,
Christopher Martin

Attachment: pgpPLV5J8Ogqf.pgp
Description: PGP signature


Reply to: