Bug#403639: Fix committed in svn repo

[Attilio Fiandrotti]

Hi

Just wanted to say the patch was eventually committed to gnome svn [1]: 
i tried a backport to our 2.8.20 but was unable to due to that complex 
set of patches already present :(
Would be possible building an experimental 2-8-20 udeb with this patch 
to see what its effects are?


thanks

Attilio

[1] 
http://svn.gnome.org/viewcvs/gtk%2B/trunk/gdk/directfb/gdkwindow-directfb.c?r1=16906&r2=17014&rev=17014&sortby=date



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#403639: Fix committed in svn repo

[Loïc Minier]

On Mon, Jan 08, 2007, Attilio Fiandrotti wrote:
> Just wanted to say the patch was eventually committed to gnome svn [1]: 
> i tried a backport to our 2.8.20 but was unable to due to that complex 
> set of patches already present :(
> Would be possible building an experimental 2-8-20 udeb with this patch 
> to see what its effects are?

 It's not trivial to backport, the upstream 2.10 code doesn't map so
 well with our 2.8.20 with backported directfb and I think it wouldn't
 be possible to pull the 2.10 directfb files as they rely on the
 internal 2.10 functions.  :-/

 I've applied the patch by hand the best I could, it built, could you
 please try the packages at:


-- 
Loïc Minier <[EMAIL PROTECTED]>

Bug#403639: Fix committed in svn repo

[Attilio Fiandrotti]

Loïc Minier wrote:

On Mon, Jan 08, 2007, Attilio Fiandrotti wrote:

Just wanted to say the patch was eventually committed to gnome svn [1]: 
i tried a backport to our 2.8.20 but was unable to due to that complex 
set of patches already present :(
Would be possible building an experimental 2-8-20 udeb with this patch 
to see what its effects are?



 It's not trivial to backport, the upstream 2.10 code doesn't map so
 well with our 2.8.20 with backported directfb and I think it wouldn't
 be possible to pull the 2.10 directfb files as they rely on the
 internal 2.10 functions.  :-/


Yes, i know this patch adds comlexity to gtk+ 2.8.20, which is growing 
to be a complicated hairball..



 I've applied the patch by hand the best I could, it built, could you
 please try the packages at:




thanks for patching: i built an iso [1] and it looks like leakage is now 
small during normal questions display and still noticeable during 
progressbar runs.
I'd like someone else than me (Frans?) give this iso a objective test 
and report if he thinks the leakage is now reduced.
By my side, i'll investigate why we still leak when a progressbar is run 
(this puzzles me, as the progressbar is never destroyed, just hidden).


Attilio

[1] https://debian.polito.it/downloads/mini_gtk+_2.8.20-4.iso


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#403639: Fix committed in svn repo

[Frans Pop]

Hi Loïc,

Again our thanks for your quick and excellent response.

On Tuesday 09 January 2007 20:12, Loïc Minier wrote:
>  It's not trivial to backport, the upstream 2.10 code doesn't map so
>  well with our 2.8.20 with backported directfb and I think it wouldn't
>  be possible to pull the 2.10 directfb files as they rely on the
>  internal 2.10 functions.  :-/
>
>  I've applied the patch by hand the best I could, it built, could you
>  please try the packages at:
>
> 

I have tested the udeb from that location by rebuilding the installer with 
as only change that udeb, and I can confirm that the memory leaks are 
(almost?) completely gone. I have done a full installation and not 
noticed any regressions or problems.

If there still is a memory leak due to progress bars, it must be very 
small and could probably be ignored for Etch, but I'll let Attilio decide 
on that.

Loïc: How invasive is this patch? How would you judge the risk of 
regressions? Do you feel comfortable defending it for the RMs?

Thanks again,
FJP


pgpKVMBGaBaOM.pgp
Description: PGP signature

Bug#403639: Fix committed in svn repo

[Loïc Minier]

On Thu, Jan 11, 2007, Frans Pop wrote:
> I have tested the udeb from that location by rebuilding the installer with 
> as only change that udeb, and I can confirm that the memory leaks are 
> (almost?) completely gone. I have done a full installation and not 
> noticed any regressions or problems.

 Ah, I'm relieved.  I was fearing the pathes we might have to follow
 would the patch not improve the situation. :)

> Loïc: How invasive is this patch? How would you judge the risk of 
> regressions? Do you feel comfortable defending it for the RMs?

 I was never enchanted by the nature of the directfb backport to gtk
 2.8 and this is based on an upstream fix, so I don't feel too dirty
 in appliying it if it plugs an important memory leak.
   The cleanup code that it fixes seems to have been incomplete in our
 directfb backport, we didn't keep the backport up-to-date (which would
 have been too much effort anyway), so it was to be expected that such
 issues pop up.  This code is also very tricky, which means I can't
 really criticize it technically as I don't understand it fully.
   Finally, since the patch involves directfb specific code and since
 d-i is the main consumer of this code, I think this is ok to go.  In
 fact, I don't have anything better to offer. :)

 I've uploaded these debs to unstable.

-- 
Loïc Minier <[EMAIL PROTECTED]>

Bug#403639: Fix committed in svn repo

[Frans Pop]

On Thursday 11 January 2007 18:21, Loïc Minier wrote:
>  I've uploaded these debs to unstable.

OK, thanks. That means that we can get some more testing in before 
requesting migration.

Let's hope that with Lenny we can switch to a truly integrated 2.10 soon.

Cheers,
FJP


pgput4aJ63xhI.pgp
Description: PGP signature

Bug#403639: Fix committed in svn repo

[Josselin Mouette]

Le jeudi 11 janvier 2007 à 18:30 +0100, Frans Pop a écrit :
> On Thursday 11 January 2007 18:21, Loïc Minier wrote:
> >  I've uploaded these debs to unstable.
> 
> OK, thanks. That means that we can get some more testing in before 
> requesting migration.
> 
> Let's hope that with Lenny we can switch to a truly integrated 2.10 soon.

2.10 packages are still available in experimental if you want to test.
With 2.10.7 they seem to have finally reached enough stability for
unstable (but not during a freeze, heh).
-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Bug#403639: Fix committed in svn repo

[Attilio Fiandrotti]

Frans Pop wrote:

On Thursday 11 January 2007 18:21, Loïc Minier wrote:


I've uploaded these debs to unstable.



OK, thanks. That means that we can get some more testing in before 
requesting migration.


Let's hope that with Lenny we can switch to a truly integrated 2.10 soon.


I strongly agree: gtk/dfb has an always evolving codebase, with many 
important fixes (about to be) recently committed and backporting every 
one of them to 2.8 would be a real pain.

No luck yet in tracking down mem leaks during progressbar runs :(

Attilio


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]