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

Re: Gtk 2.10 availability

On Wed, Sep 20, 2006, Frans Pop wrote:
> The main question I guess is: is there more information on if/when 2.10 
> could migrate to unstable? What is the chance that it will make Etch?

 The biggest instability in Gtk 2.10 is due to the new filesystem module
 asynchronous implementation.  In short, this feature permits opening
 the "File open..." dialog (the "picker") empty, and filling it's
 content in a separate thread while continuously responding to user
 input.  In other word, the UI doesn't hang when opening a large
   This particular issue was a bit rushed to make it in 2.10, and it
 was afterwards considered to revert its inclusion.  See the upstream
 thread for details:

 It seems upstream is currently trying to address all known issues
 related to this change instead of reverting the code, so I suppose Gtk
 2.10.4 will show whether they have succeeded in stabilizing this

 Another problem of switching to Gtk 2.10 is the transition it involves
 due to the backward incompatibility with modules.  This affects 19
 source packages,  three of these are under the control of the GNOME
 team.  The transition needs some source changes, but these are
 relatively simple.  IMO, the advantages release-wise of the new Gtk
 counter-balance this transition, but this didn't get any release team
 acceptance yet.

 One important part of the decision will be on the side of debian-boot@
 as well.  It is not innocently that I wishes you test the Gtk 2.10
 udebs.  If you do happen to find showstoppers for your uses of Gtk with
 the new release, it might kill the idea of 2.10 in etch.  On the
 contrary, if you happen to find big advantages of 2.10 over 2.8, it
 would be an argument in favor of pushing 2.10 into etch.

> Main reason I ask is that there are a few RC issues in the graphical 
> installer (not crashes, but important presentation issues) that should be 
> solved in 2.10, but are still present in 2.8.
> If the chance that 2.10 will _not_ make Etch is high, then we need to try 
> to find fixes for these issues in 2.8. If that chance is negligible, we 
> can concentrate on testing with the 2.10 libs.

 I don't think the chances are negligible, so I'm willing to work on any
 outstanding issues that you see with 2.8 to build a solid backup plan.
 (Please continue focusing on 2.10 as the primary target though.)

 Here's what is already ready for a gtk+2.0 2.8.20-2 upload:
  * New patch, 009_revert-gdkdrawable-directfb, to revert a fix for Italic
    letters which caused ugly unneeded horizontal/vertical lines; thanks
    Davide Viti. (Closes: #386860)
  * Fix typo, install-dfb depends on build-dfb, not build-shared.

 Other things that need to be done:
 - addition of the pixmap engine
 - fix the empty /etc/gtk-2.0/gdk-pixbuf.loaders (#382435)

 Could you list any other thing that you consider RC or important that
 still need fixing in 2.8?

> No, cdebconf in unstable is built against libgtk-directfb-2.0-dev
> So we do need to make this change.

 Oh, my mistake, I was looking at the sources both in etch and sid at
 the same time, and didn't notice cdebconf/sid was using the new lib.

 Then the changes I have described are recommended indeed (but the
 current package will continue building exactly as well as it did until

Loïc Minier <lool@dooz.org>

Reply to: