On Thursday 20 April 2006 00:50, Attilio Fiandrotti wrote: > Looking at the wiki page, i saw the transition to newer g-i libraries > is at the first place in the meeting agenda.
Uh, that is not quite correct. What is first on the agenda is the udeb _dependency_ transition, which is what's needed to integrate g-i into the main build scripts and thus influences Beta 3. See: http://wiki.debian.org/DebianInstaller/LibraryUdebs Does not mean we cannot also talk about newer libraries for g-i :-) > I've been recently experimenting with the creation of udebs from GTK > and Cairo from CVS compiled against DFB 0.9.24 to test how much painful > the transition would be (so far, bugs #362858 and #362860 were found). > After some testing i found GTK 2.9 CVS snapshot dated 20060328 to > compile and work with DFB 0.9.24 (later GTK snaphots were broken). What > do we want to do about the GTK libraries? waiting until 2.10 is > released or create a cvs udeb against DFB 0.9.24 ? in the case we want > to go with the CVS solution, i can provide help and also precompiled > i386 binaries (sadly, i failed in creating hacked udebs). The problem remains that we cannot just dump random packages with random libraries into the official Debian archives. Especially if these packages will conflict with the current versions packaged by the official maintainers. So any solution using new libraries would have to use tarballs and IMO that would be a step back from what we have. Also, I don't feel it would be right to integrate g-i into the official builds if we take libraries from tarballs. For use in any officially built images, we have to wait until new upstream versions are released and packaged by their official packagers. Of course, any preparation we can do to help them quickly create the new udebs we will need is very useful. > Having GTK 2.9 available for testing in the g-i would give us RTL text > in SELECT/MULTISELECT question and would also help in finding bugs in > the DFB backend before GTK 2.10 is released. Yes, I agree, but given the above, I think that should remain something that is done privately, based on instructions from the wiki (possibly with the help of unofficial tarballs or packages that we could host somewhere on alioth). > Also, it would be nice staring to think how to package into an udeb that > nice "Bladr" GTK theme Luca Bruno created [1]. That is independent, unless new libraries are required for that. Cheers, FJP
pgprRg2ywb2Bd.pgp
Description: PGP signature