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
https://debian.polito.it/downloads/miniisofiles/
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 :)
ciao
Attilio
Reply to: