Please allow kdenetwork and kdelibs into Sarge
Hello,
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:
kdenetwork (4:3.3.2-3) unstable; urgency=high
* Urgency high because we fix a recently discovered FTBFS that prevents
the previous medium-urgency upload to migrate to testing. Only
debian/control is changed in this upload.
+++ Changes by Adeodato Simó:
* xmms-dev has recently moved from depending on xlibs-dev to specifying
the exact list of development libraries needed (see Bug#302059), which
makes kdenetwork fail to build from source now, Add libxtst-dev to
Build-Depends. (Closes: #305942)
* Make ksirc recommend libio-socket-ssl-perl, so that SSL connections
work. Mention this in the package description. (Closes: #294331)
-- Debian Qt/KDE Maintainers Sat, 23 Apr
2005 04:51:30 +0200
kdenetwork (4:3.3.2-2) unstable; urgency=medium
+++ Changes by Christopher Martin:
* KDE_3_3_BRANCH update. Kopete loses rich-text support in ICQ, but works
around an exploitable crash when contacted by icq5 clients. Bump urgency to
medium since these fixes are RC. (Closes: #295265, #297861)
* Change kopete's section to kde. (Closes: #292398)
* Include the GFDL in debian/copyright, since the Handbooks are licensed
under it.
* Daniel Stone has kindly relicensed man pages written by him from GDFL to
GPL, update copyright notice in kopete.1.
+++ Changes by Adeodato Simó:
* kopete no longer depends on XMMS, which it did simply because the Now
Listening plugin was linked against libxmms. Added a patch to dlopen
libxmms at runtime and use it if present, so that the plugin remains
functional even if XMMS is not installed. (Closes: #238368, #276586,
#292963, #293191)
-- Debian Qt/KDE Maintainers Wed, 30 Mar
2005 11:49:58 +0200
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;
}
Thanks for all your work,
Christopher Martin
pgpnvOeqyl3ax.pgp
Description: PGP signature
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
pgpPQzrNKVIy5.pgp
Description: PGP signature
Re: A Prisonner of the dependency hell
On May 28, 2005 15:47, Bill Allombert wrote: > After spending a dozen of hour tracking it, I have the obvious headache, > but also the following: > > 1) debootstrap woody > > 2) Install the following packages: > konqueror aptitude libqt3 libhtml-tree-perl libapt-pkg-perl libft-perl > > 3) point apt at sarge. > > At this point you are between a rock and a hard place: > You can do > 2) aptitude install aptitude, but that remove konqueror and perl > 3) aptitude dist-upgrade, but that remove konqueror Interestingly, not having libqt3 installed (after debootstrap, just installing konqueror and aptitude) alleviates the problem to the point of matching the results in http://release.debian.org/kde-upgrade.txt, which explains why the issue was thought to be resolved. On May 28, 2005 18:48, Steve Langasek wrote: > Did you install konqueror and libqt3 with aptitude, or with another tool? > If konqueror is installed with aptitude, allowing libqt3 to be pulled in > automatically, does aptitude do a better job of conflict resolution on > upgrade? Konqueror in Woody doesn't pull in libqt3 automatically, since KDE in Woody still used Qt2. > So, this works: > > aptitude markauto libqt3 > perl -pi -e's/stable/sarge/' /etc/apt/sources.list > apt-get update > aptitude dist-upgrade A libqt3 dummy package, without dependencies, also seems to suffice to keep Woody's aptitude from removing konqueror when performing a dist-upgrade. It does nothing for apt-get and dselect, though, so it's not of much help except to eliminate the need for aptitude users to ensure that libqt3 is marked auto. Further work needed... BTW, I'd like to thank Bill Allombert for all his help with this issue. Cheers, Christopher Martin pgpzPouQNZTBI.pgp Description: PGP signature
