Hi folks. Sorry, no patches, sources, or udebs, at least for now. (Yes, this is a teaser; booh, bad bad bad KiBi.) I just wanted to keep you posted about my latest hacks. Please note the following numbers are based on my IRC backlog between successive builds, so they might not be the exact figures for the final v1 → v2 update; they should give a clue though. (There could be typos, too.) (If you want to quick-read it, bottom-line available for each source package after the ‘⇒’ sign.) Already done: ============= * xorg-server: We can link statically against libgcrypt & libgpg-error for the time being. That means a 2016 → 2460 increase for the Installed-Size, but also 2 udebs we don't need to add. While this is a huge increase, we should be able to link statically against libmatrixssl only, once its -dev package ships all needed headers so that we can use its matrixSha1* functions. The increase I noted when building statically against libmatrixssl was 2012 → 2032, which seems much more reasonable. In all cases, that means we don't need to deal with extra udebs for just SHA1 computations (!), and that we could start shipping an xserver-xorg-core-udeb right now, there's (AFAICT) no more doubt about udebs we might try to get rid of (at least based on the previous observations). ⇒ Less udebs needed, less space used. * udev: The previous patch set wasn't really good indeed. I've left udev-udeb untouched this time, and put input_id, the needed rule and libudev.so.0.6.1 in the new one, and registered it as shlibs through --add-udeb. It additionally Depends: udev-udeb, meaning once the xserver-xorg-core-udeb built against the new libudev-dev, it get a Depends on udev-gtk-udeb, which in turn pulls udev-udeb. (I'm not sure we should name it udev-gtk-udeb since there's nothing gtk-related in there, it'd rather be X11-related, but frankly, I don't care. :)) ⇒ Fixed relationships and contents for udev's udebs. * gtk+2.0: Julien's patch against its configure.in did the trick and a few X libraries got dropped: libxcomposite1, libxdamage1, libxfixes3, libxrandr2. That means fewer udebs to add (although libxfixes3 is still pulled by libxcursor1), which is what we tried to achieve. That also means I'm back to using an additional flavour (shared_udeb but the name isn't really important) instead of the regular flavour (shared), since there are now additional flags; anyway, gtk+2.0 folks are already in favour of this flavour addition. ⇒ Less udebs needed, less space used. * xkb-data: Stripping the *.mo files got the Installed-Size down for real: 4700 → 3068. As I said in a comment in my initial patch, I really considered the udeb an exact copy as a first guess, and moved on to the interesting parts which were Xorg itself and the whole Cairo/Pango/Gtk stack, which sounded like the real challenge back then. :) ⇒ Less space used. Now on my todolist: =================== * Wait for some feedback about the cursors, and tweak the cursor package accordingly. ⇒ Possibly better look, less space used. * Have a look at cleanly generating the stripped-down XML file for gtk+2.0 (a few lines of xslt should do, although we don't really need this *right now*, since I've put a manually-built minimal XML file in both my initial and updated gtk+2.0 patches). ⇒ Cleaner approach. * Publish a v2 of all patches, source packages, and udebs, so that people can have another look. If no blocker is found, I guess we may want to start adding the udebs for real at this point? From my point of view, only xorg-server might be a bit of a moving target depending on how and when the gcrypt/gpg-error → matrixssl switch happens. ⇒ I don't like keeping stuff for myself. * Maybe look into mklibs. It might be easier for people familiar with this tool to dig into it once I've published my updated patches, though. ⇒ Possibly drastically reduce space. As always, I take comments, ideas, flames, whatever you throw. :) Mraw, KiBi.
Attachment:
signature.asc
Description: Digital signature