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

KDE status for progression into testing...



I was poking around looking for the current holdups for getting KDE
into sarge.

There's openldap2, of course, but the OpenLDAP maintainers are preparing 
a new release of OpenLDAP fixing all the RC bugs as we speak, and it
will probably be in unstable in the next couple of days, and testing 10 
days after that.  A nice goal would be to have most of kde go in at 
approximately the same time...

kdelibs has 
* one sarge-only bug
* one unreproducible bug
-- hopefully this won't affect progression into testing
* one other serious bug, which is actually two issues:
kdelibs4-dev (meinproc) needs to depend on libxml2-utils
-- this should hopefully be fixed with the next upload of kdelibs
   (maybe someone should upload...)
meinproc fails mysteriously on m68k
-- I hope the whole of KDE is not held up for this, even if it would be 
  an architecture breakage.  Anyway, it seems to be the last open 'real' 
  bug, so fixing it would be a very good thing to do.  Unfortunately,
  that can only be done by m68k people.

kdebase has:
* a dependency bug: ksysguard needs to depend on libsensors-1debian 
rather than libsensors1
-- will hopefully be fixed with the next upload
   (maybe someone should upload...)
* a FTBFS with a patch which fixes it
-- should hopefully be fixed in the next upload
   (maybe someone should upload...)
* a wontfix upstream bug
-- hopefully this won't affect progression into testing
* three woody-only bugs

kdegraphics has one RC bug
* another obsolete dependency (imlib2 instead of libimlib2)
-- will presumably be fixed with the next upload
   (maybe someone should upload...)

Of the remaining packages depended on by meta-kde, none have RC 
bugs, and it doesn't look like there are any serious dependency 
problems.

(kdepim is waiting (indirectly) for gdbm, which sounds bad.  But 
apparently
(http://lists.debian.org/debian-release/2003/debian-release-200306/msg00026.html)
most of the 'breakage' for gdbm is spurious, and simply means that
gdbm and gdbm173 must be pushed in together.  It needs a new apache2,
but that's only waiting for openldap2.)

There's a fair number of packages which are out-of-date on various 
architectures, but there's probably no point worrying about that until
the known bugs above are fixed.

-- 
Nathanael Nerode  <neroden at gcc.gnu.org>
http://home.twcny.rr.com/nerode/neroden/fdl.html



Reply to: