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

Re: GTK miniiso - status and instructions for building

Frans Pop wrote:
On Sunday 02 October 2005 14:42, Attilio Fiandrotti wrote:
Any idea why the frontend failed to load the logo for all my tests yesterday? As far as I could tell the path to the logo was set correctly...

it's a bug in my hand-made libs: on GTKX, GTKDFV 2.7.2, GTKDFB 2.0.9-5 from libgtk+2.0-directfb-udeb-dev_2.0.9-5_i386.deb
logo shows correctly.

Hmm. The breakage showed up during my first tests when I had a working installer. Today Christian Perrier reported that he saw the list correctly, and with my latest build I see the same.
So it looks like you can re-enable this. Sorry for the confusion.

Could you make a new frontend available?

handler re-enabled in SVN; go to


and grab all the updated tarballs you find in that dir and upload them to alioth (d-i_gtk_directfb.tgz and d-i_gtk_fonts.tgz are not present since don't need to be updated to alioth ) After a lot of efforts to remove unneded files from .TGZs now the situation is:

- d-i_gtk_frontend.tgz contains ONLY gtk.so compiled against my hand-made libgtk+-directfb libs. From now on gtk.so in d-i_gtk_frontend.tgz is chown'ed to 0:0 and chmod'ed 644.

- d-i_gtk_root.tgz contains ONLY my libc-2.3.5.so that is needed to make gtk.so work (no more other files in /lib nor /etc directory)

- d-i_gtk_directfb.tgz contains my hand made libgt+-directfb (and related files)

- d-i_gtk_fonts.tgz contains fonts: actually they don't work and we must understand why (maybe fontconfig or pango related issues?)

You seem confused as to which environment to use. For development work, you should always use unstable (sid). This is because packages have to be uploaded to unstable. The daily builds are also done from udebs in sid.

alright, experiments and developement is always done with sid, that one was just a dirty cross-test of my own..

So i suppose gtk.so should be compiled against development files coming
from "libgtk+2.0-directfb-udeb-dev" from "stable", right? i've compiled

No, these are no longer usable. Davide has been working on this, but not achieved the correct result yet.

so we must get a new .deb that allows us to compile a gtk.so that works with the latest libgtk+-directfb.so from Alastair's udeb, right? Doing some regression-test with libdirectfb-0.9-20-udeb_0.9.20-5_i386.udeb and libdirectfb-0.9-20-udeb_0.9.20-5_i386.udeb and a gtk.so compiled against libgtk+2.0-directfb-udeb-dev_2.0.9-5_i386.deb was a failure also.

It seems a lot of work has yet to be done to make libgtk+directfb udeb work/ obtaining a gtk.so that works with existing libgtk+directfb udeb.
So i ask myself if it's better

a)Try to make the libgtk+directfb 2.0.9.x.y udeb work to get rid of unneded archives immediatly and later switch to GTKDFB 2.8

b)Stay with .tgz archives (including my libgtk+directfb libs & related files) until GTKDFB 2.8 is ready to be packaged

what's the best choiche? i canot tell , but we bust balance the time to get aeverything as udebs and minimization of efforts to make things work. ATM no one has ever packaged GTKDFB 2.8 and this may be a tought one, so it's better save our energies now and use them in the future to pack GTKDFB 2.8.
What do you think? this is an important decision to be taken..

anyway i'm very happy how things are going on :)



Reply to: