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

Christopher Martin Christopher Martin <christopher.martin@utoronto.ca>
Tue, 10 May 2005 09:28:36 -0400


--nextPart2130839.zIpHcg7gtY
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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=
,=20
which is when we started thinking in terms of ease-of-readability. As for=20
uuencoding, it is, unfortunately, necessary when binary files are=20
added/updated in a diff. The use of -a when generating a diff doesn't seem=
=20
to prevent dpkg from choking on it. While for the KDE 3.3 packages all=20
branch diffs are uuencoded (more out of tradition than anything else),=20
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 =3D 0; o < m_numrows; o++)
> > -                       if (m_starttab[o] + m_lengthtab[o] >=3D
> > m_data.size()) {
> > +                       // do not convert to >=3D
> > +                       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=20
http://www.kde.org/info/security/advisory-20050504-1.txt. In summary, most=
=20
RGB files (an older SGI format, but it's still around) can no longer be=20
read. The one-line change (from upstream) we added between -5 and -6 fixes=
=20
this regression.

Cheers,
Christopher Martin

--nextPart2130839.zIpHcg7gtY
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Signed by Christopher Martin <chrsmrtn@freeshell.org>

iD8DBQBCgLcJU+gWW+vtsysRAug3AJwNu0qedCQXZQVV8En/f1h/NOnEcACgge3J
a6nNbfSVhC8g//OeECZLIeo=
=cp1L
-----END PGP SIGNATURE-----

--nextPart2130839.zIpHcg7gtY--