Re: KDE 3.3 and sarge
KDE 3.3 is out, which is fine, but is Qt 3.3 planned for Sarge? It's been
in Sid for a while, so a lot has been built against it. However, it is not
100% perfectly backwards compatible with Qt 3.2. For instance, gwenview (a
KDE image viewer I maintain) needs to be rebuilt against Qt 3.3 to solve a
nasty problem getting out of fullscreen mode. Since Sid has kdelibs 3.3.0,
uploads must go to testing-proposed-upgrades - but I must wait until after
Qt 3.3 arrives in Testing, otherwise there is no point. Since the bug
solved isn't truly release critical (but I would really hate to ship with
nevertheless), I'm worried that my upload will be rejected (and my sponsor
is on vacation, so I'll need someone else to actually make the upload in
any case). What to do? Just wait for Qt 3.3 to propagate to Testing and
[get someone to help] upload?
Quoting Steve Langasek <email@example.com>:
> [Please cc: debian-release on replies.]
> As some of you probably already know, a number of packages from KDE
> have been uploaded today to unstable. This upload of a major new
> upstream release was not discussed with the release team prior to
> upload; actually, it's caused quite a bit of consternation and
> made for a crappy day on account of the impact on the libtiff freeze.
> The problems for libtiff have, however, been sorted at this point.
> Consequently, this note is to let maintainers of KDE packages know
> the release team does not plan to delay the freeze for KDE3.3. After
> discussing with Ben Burton, it is clear that allowing only part of
> 3.3 into sarge so close to the freeze is likely to lead to new bugs,
> that any attempt to get all of KDE3.3 into sarge at this point would
> unacceptably delay the release schedule.
> If you maintain KDE-related packages that still need to be updated
> sarge, this means that you will need to upload your changes to
> testing-proposed-updates after discussing them with the release team
> first, because any packages built against unstable will have an
> unsatisfiable versioned dependency on kdelibs. You can thank Chris
> Cheney for this turn of events.
> I am aware that testing-proposed-updates will be needed for
> kdelibs, and kdebase because of a combination of security fixes and
> still outstanding requirement to get rid of libtiff3g for sarge. Ben
> Burton has already expressed his willingness to NMU these packages if
> necessary; Chris, if you are available to work on this yourself, I am
> course happy to work with you to get these packages ready for sarge.
> These uploads will in any case have to wait for libtiff4 to reach
> which should happen in two to three days once the new libtiff3g
> is built on all architectures.