Re: Gtk 2.10 (DirectFB) progress report - update
On Sun, Sep 03, 2006, Dave Beckett wrote: I've done this. libcairo 1.2.4-2 is now uploaded to experimental. Works great! Thanks, I've uploaded a snapshot of ongoing Gtk 2.10 work to experimental. One thing though: I think it would be safest to bump the libcairo-directfb2 shlibs as, currently, a gtk built against a PS/PDF enabled libcairo-directfb might not run against one. (I didn't bump the gtk build-dep on this PS/PDF libcairo-directfb-dev right now, but gtk/i386 in experimental is built against this new libcairo-dfb.) -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 (DirectFB) progress report - update
Loïc Minier wrote: Hi, On Thu, Aug 31, 2006, Attilio Fiandrotti wrote: i did some testing today compiling gtk+ from CVS HEAD against libcairo-directfb2 (1.2.4-1) and libdirectfb-0.9-25 (0.9.25.1-3) and it turns out that - a fresher DirectFB than the latest release (0.9.25.1); I hope the DirectFB maintainer has the time to prepare a snapshot for experimental as requested in Debian #383238 this is no longer a problem, as GTK+ = 2.10.2 selectively excludes from compilation all the code that needs DFB = 0.9.26 to work (minimum requirement is now DFB 0.9.24) Yes, actually I continued working on Gtk 2.10.0 in our SVN but backported the needed delta from Gtk's CVS back then (this was before the relevant Gtk release). This is in pkg-gnome's SVN since 10 days or so. The GDKDFB backend found in GTK+ 2.10.2 contains many very important enhancements and fixes Mike Emmel introduced Fri Aug 11, which are not found in earlier (2.10.0, 2.10.1) GTK+ relases. I strongly suggest to skip GTK+ 2.10.0 and 2.10.1 and jump directly to GTK+ 2.10.2. snip/ - to rebuild Cairo against the new DirectFB which changes SONAME, I hope an upload to experimental will be possible once DirectFB is uploaded but I've not requested that yet current cairo-directfb depends from DFB 0.9.25, so i guess this is solved ? Correct, this was only required because of the first point. cool! :) Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 (DirectFB) progress report - update
Dave Beckett wrote: snip/ No, do not do this. I already said that I won't change/bloat the cairo+directfb udebs that are for the installer. They don't need PDF and PS support and do need lib/dev debs that match the udeb so that other udebs can be built against them, such as the gtk+directfb udeb. If your only concern is about cairodfb size, i guess having the system libraries passing thru mklibs before being installed into the d-i ISO image will cut away any unneded symbol like all the GTK+ printing stuff. PS and PDF cairo's backends are required by the printing stuff introduced in GTK 2.10 series, which is usually unuseful in embedded devices. I remember plans for post 2.10 GTK+ releases were to allow selective disabling compilation of the printing stuff, but there is little chance this feature to be introduced in GTK 2.10 series. - to rebuild Cairo against the new DirectFB which changes SONAME, I hope an upload to experimental will be possible once DirectFB is uploaded but I've not requested that yet current cairo-directfb depends from DFB 0.9.25, so i guess this is solved ? Correct, this was only required because of the first point. Is this gtk bump is really required for the etch release? At this stage I'm not seeing why gtk+directfb is a priority to have versus having stability of libraries. Current GTKDFB 2.8.20 libraries found in debian repositories contain an old DFB backend i backported some months ago from GTK 2.9.x, and this backends not only has poor performance in some cases, but is also affected by a couple of serious bugs (like #385026) that were solved in GTK+ 2.10.2 release. If necessary we'll have to make a 3rd rebuild of cairo. I'm wondering about having two source packages, one that builds the udeb+deb cairo+directfb minimal (which can be subjected to release freezes) and the other that builds the cairo/cairo+directfb with full features. Or can I just enable directfb in the main cairo build? Do you really want a cairo with no X? Yes, please: the GTK on DFB project is raising interest between people involved in embedded linux development because the possibility to run a GTK app without running an X server too. Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 (DirectFB) progress report - update
Hi, On Sat, Sep 02, 2006, Dave Beckett wrote: I already said that I won't change/bloat the cairo+directfb udebs that are for the installer. They don't need PDF and PS support and do need lib/dev debs that match the udeb so that other udebs can be built against them, such as the gtk+directfb udeb. I agree that we don't need the PDF/PS support in cairo's udebs because we don't need printing support in gtk's udebs, but since I can't easily cut away printing support in gtk, I now need cairo udeb with PDF/PS support. I don't know whether it's an useful measure of the final real runtime memory consumption, but the *.so sizes are: 316Kusr-nopdf/lib/libcairo-directfb/lib/libcairo.so.2.9.1 364Kusr/lib/libcairo-directfb/lib/libcairo.so.2.9.1 which is a non-negligible 15% indeed. Is this gtk bump is really required for the etch release? At this stage I'm not seeing why gtk+directfb is a priority to have versus having stability of libraries. That's a good question, but I think we at least need to try, and that involves building stuff in experimental, and testing. If necessary we'll have to make a 3rd rebuild of cairo. I'm wondering about having two source packages, one that builds the udeb+deb cairo+directfb minimal (which can be subjected to release freezes) and the other that builds the cairo/cairo+directfb with full features. That's a bit risky, but we can try; I guess we will immediately see whether some symbols are missing. Or can I just enable directfb in the main cairo build? Do you really want a cairo with no X? I prefer the current approach; it bloats less DirectFB only apps. I don't know any app which would benefit from a DirectFB+X cairo. Bye, -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 (DirectFB) progress report - update
Loïc Minier wrote: Hi, On Sat, Sep 02, 2006, Dave Beckett wrote: I already said that I won't change/bloat the cairo+directfb udebs that are for the installer. They don't need PDF and PS support and do need lib/dev debs that match the udeb so that other udebs can be built against them, such as the gtk+directfb udeb. I agree that we don't need the PDF/PS support in cairo's udebs because we don't need printing support in gtk's udebs, but since I can't easily cut away printing support in gtk, I now need cairo udeb with PDF/PS support. This information seems the deciding point - you can't get rid of this requirement from building gtk. So... I don't know whether it's an useful measure of the final real runtime memory consumption, but the *.so sizes are: 316Kusr-nopdf/lib/libcairo-directfb/lib/libcairo.so.2.9.1 364Kusr/lib/libcairo-directfb/lib/libcairo.so.2.9.1 which is a non-negligible 15% indeed. yes. But despite this, you need it. So as long as the debian-boot team realises this, I'm ok with adding it to the default cairo+directfb build; i.e. I will add the --enable-pdf and --enable-ps to the builds. Is this gtk bump is really required for the etch release? At this stage I'm not seeing why gtk+directfb is a priority to have versus having stability of libraries. That's a good question, but I think we at least need to try, and that involves building stuff in experimental, and testing. If necessary we'll have to make a 3rd rebuild of cairo. I'm wondering about having two source packages, one that builds the udeb+deb cairo+directfb minimal (which can be subjected to release freezes) and the other that builds the cairo/cairo+directfb with full features. That's a bit risky, but we can try; I guess we will immediately see whether some symbols are missing. So what I propose is that I'll make some experimental packages with the PDF+PS enabled and you can try building with them. Although from your earlier emails, I expect this will just work since you've been trying this already. Or can I just enable directfb in the main cairo build? Do you really want a cairo with no X? I prefer the current approach; it bloats less DirectFB only apps. I don't know any app which would benefit from a DirectFB+X cairo. OK. You replied in another email about embedded users of gtk, and I can see that as making this worthwhile to package and ship. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 (DirectFB) progress report - update
On Sun, Sep 03, 2006, Dave Beckett wrote: I'm ok with adding it to the default cairo+directfb build; i.e. I will add the --enable-pdf and --enable-ps to the builds. Great! That's a bit risky, but we can try; I guess we will immediately see whether some symbols are missing. So what I propose is that I'll make some experimental packages with the PDF+PS enabled and you can try building with them. Although from your earlier emails, I expect this will just work since you've been trying this already. Sure, that will work. (What I considered risky was the triple build where I build against one version of cairo+directfb which has PS+PDF, but the udeb version of cairo+directfb doesn't.) Thanks! -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 (DirectFB) progress report - update
Loïc Minier wrote: On Sun, Sep 03, 2006, Dave Beckett wrote: I'm ok with adding it to the default cairo+directfb build; i.e. I will add the --enable-pdf and --enable-ps to the builds. Great! I've done this. libcairo 1.2.4-2 is now uploaded to experimental. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 (DirectFB) progress report - update
Loïc Minier wrote: ... - to rebuild the DirectFB flavor of Cairo with --enable-pdf and --enable-ps as requested in Debian #383297 still awaiting the patch to be applied, currently GTK+ from HEAD does not compile against DFB flavour of cairo from debian packages because of lack of PDF and PS support. Indeed, I hadn't any new from Dave Beckett either. Dave, would you mind if I NMU libcairo with the proposed changes perhaps to experimental if you so prefer? No, do not do this. I already said that I won't change/bloat the cairo+directfb udebs that are for the installer. They don't need PDF and PS support and do need lib/dev debs that match the udeb so that other udebs can be built against them, such as the gtk+directfb udeb. - to rebuild Cairo against the new DirectFB which changes SONAME, I hope an upload to experimental will be possible once DirectFB is uploaded but I've not requested that yet current cairo-directfb depends from DFB 0.9.25, so i guess this is solved ? Correct, this was only required because of the first point. Is this gtk bump is really required for the etch release? At this stage I'm not seeing why gtk+directfb is a priority to have versus having stability of libraries. If necessary we'll have to make a 3rd rebuild of cairo. I'm wondering about having two source packages, one that builds the udeb+deb cairo+directfb minimal (which can be subjected to release freezes) and the other that builds the cairo/cairo+directfb with full features. Or can I just enable directfb in the main cairo build? Do you really want a cairo with no X? Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 (DirectFB) progress report - update
Hi i did some testing today compiling gtk+ from CVS HEAD against libcairo-directfb2 (1.2.4-1) and libdirectfb-0.9-25 (0.9.25.1-3) and it turns out that - a fresher DirectFB than the latest release (0.9.25.1); I hope the DirectFB maintainer has the time to prepare a snapshot for experimental as requested in Debian #383238 this is no longer a problem, as GTK+ = 2.10.2 selectively excludes from compilation all the code that needs DFB = 0.9.26 to work (minimum requirement is now DFB 0.9.24) - to rebuild the DirectFB flavor of Cairo with --enable-pdf and --enable-ps as requested in Debian #383297 still awaiting the patch to be applied, currently GTK+ from HEAD does not compile against DFB flavour of cairo from debian packages because of lack of PDF and PS support. - to rebuild Cairo against the new DirectFB which changes SONAME, I hope an upload to experimental will be possible once DirectFB is uploaded but I've not requested that yet current cairo-directfb depends from DFB 0.9.25, so i guess this is solved ? cheers Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
