On Sunday 02 October 2005 14:42, Attilio Fiandrotti wrote: > Frans Pop wrote: > > Issues I've found. > > - The logo is no longer displayed after it was moved to /etc. > > In fact, /etc is not the correct place either. I've included the > > logo in the rootskel-gtk udeb (in /usr/share/graphics). > > Attilio: can you make the frontend look for it there? > > done and committed to SVN 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... > > - The change in country selection is broken. The frontend crashes if > > I select English and then "other" for country: the long list is no > > longer displayed correctly. > > this is strange since after checkin out evrything from scratch (udebs, > .tgzs, build system ) everything was still working fine even when > selecting English and then other. 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? > Anyway GTKDFB 2.0.9 previously showed to be affected by some strange > behaviour that do not show with GTKDFB 2.7.2. and so while > investigating about the crash i temporarily disabled the question > handler > gtkhandler_select_treeview_store() that causes the crash (this question > handler does not crashes with Etch). 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. > > To do: > > - remove the logo and /lib/libc* from d-i_gtk_root.tgz; > > if i've understood correctly the main reason that prevents us from > using Alastair's udeb and that forces us to include inside > d-i_gtk_root.tgz files like "lib/libc.so.6" and "lib/libc-2.3.5.so" is > that my gtk.so is compiled against my own hand-made libgtk+directfb > library. Yes, that is my impression, but I'm far from an expert on compiling C... > 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. > a new gtk.so against that .deb but it doesn't work with > libgtk+2.0-directfb0-udeb_2.0.9-5_i386.udeb (stable) nor > libgtk+2.0-directfb0-udeb_2.0.9.2-1_i386.udeb (unstable). > How should i compile gtk.so? and what udeb should then be used inside > the miniiso? > > > - decide where the stuff that remains in d-i_gtk_root.tgz should go: > > into the rootskel-gtk udeb or into other udebs or can be dropped; > > i hope we'll be soon able to remove d-i_gtk_root.tgz from the building > system: while doing some exepriments i've noticed that pango's udeb > creates /etc/pango.modules.dpkg-new rather than /etc/pango.modules: > this makes the frontent crash unless the correct "/etc/pango.modules" > is provided by d-i_gtk_root.tgz. > Is this a bug in pango udeb, a misconfiguration, a fault of mine or > what else? It was an error in the libpango udeb. I've now fixed it and uploaded a new udeb and a d-i_gtk_root.tgz without the /etc/pango dir and the logo. (You should do a 'fakeroot make reallyclean' after putting the new libpango udeb into localudebs!) > Anyway if those instructions are correct i would like to place them in > DebianInstallerGUIBuild wiki page. Done just now. Cheers, FJP
Attachment:
pgpw8xCmXZ34J.pgp
Description: PGP signature