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

Status of toolchain transitions in unstable



I've stopped paying attention to non-release architectures.

The following package needs to stop being built with g++ 2.95:
  xmovie -- bug 321187
    (this is a severely broken monstrosity -- maybe I'll suggest to the
     maintainer again that he just remove it from unstable)
    -- rejected from NEW queue

The following library packages still need renaming for the c2 transition:
  log4cpp -- the new maintainer hasn't managed to make a sponsored upload yet;
             see bug 303794
  postgis -- rejected from NEW queue
  sp-gxmlcpp -- bug 333885, bug 340743 should be fixed at the same time;
                they're "pending"
  wfnetobjs -- bug 332832, delays wflogs transition
               maintainer out to lunch?

For other packages which just need to be rebuilt for the C++ transition,
the best list is:
http://people.debian.org/~mfurr/gxx/rebuild.html

The following library packages have been renamed for the C++
allocator change but haven't built on all architectures yet.

  cppunit -- FTBFS on hppa (bug 341675)
  dar -- FTBFS on ia64 (binutils bug, #342777),
  usrp -- FTBFS on ia64 (due to #342780)
  ogre -- FTBFS on hppa, powerpc (possibly 343239?), RC bug 343239
  gnuradio-core -- hppa (waits for cppunit), alpha
  ace -- hppa
  tulip -- not yet tried anywhere

The following library packages need renaming for the
C++ allocator change, and the old versions are in testing:

  xalan -- big mess, removal considered
  rlog -- waiting for fuse NMU
  zipios++ -- 'pending'

The following library packages need renaming for the C++
allocator change, and are not in testing:

  alps-light1
  aqsis
  ivtools -- orphaned, also hadn't undergone c2 transition properly
  libsigcx
  openalpp-cvs
  openscenegraph
  openvrml
  osgal-cvs
  osgcal
  plptools
  qgis -- busted transition, also hadn't undergone c2 transition properly
  sqlxx
  vtk


It would be worthwhile to have Matthias go through and check for packages
exporting mt_alloc symbols again when we think we're done, to catch
packages which built against old versions of other packages.  And also
for the benefit of the architectures which I've ignored (amd64 and
all of the non-release architectures).  I'm not sure how he did the check.

I suppose it may also be worth doing the same check on testing, since I have
certainly not been keeping close track of which packages have migrated to
testing, and it's not clear whether all the bug reports were closed with
proper version tracking.

-- 
Nathanael Nerode  <neroden@twcny.rr.com>

A thousand reasons. http://www.thousandreasons.org/
Lies, theft, war, kidnapping, torture, rape, murder...
Get me out of this fascist nightmare!



Reply to: