Ho ho ho, since everybody working on KDE packaging have been good this year, you have been given faster rebuilds in KDE repos. Happy Christmas :). As some might have noticed when updating a KDE repo to a newer KDE SC version, it takes quite a while for it to rebuild, especially if Qt or kdelibs are triggered for rebuild. In fact, originally it looked roughly like this ('X' in KMail for non-proportional fonts is helpful; times are just rough measures and depend on OBS's mood, but they should match at least relatively): libqt4 1:00 (+1:00) -> libqt4-devel-doc 1:50 (+0:50) -> qt-creator 2:00 (+0:10) -> automoc4, soprano, strigi, phonon 2:20 (+0:20) -> kdelibs4 3:40 (+1:20) -> kdepimlibs4 4:00(+0:20) -> kdebase4-workspace 5:00 (+1:00) -> kdesdk4 5:30 (+0:30) -> kdevplatform 5:50 (+0:20) -> python-kde4 6:35 (+0:45) -> kdeutils4 6:55 (+0:20) -> kdepim4-runtime 5:20 (+0:20) -> kdepim4 6:30 (+1:10) -> kdegraphics4 4:05 (+0:25) -> koffice2 5:55 (+1:50) Yes, that's it, rebuilding whole of KKFD takes 5 hours if you get lucky, 7 hours if libqt4 needs a rebuild. The winner is kdeutils4. Well, actually it's not so bad anymore, as there were many unnecessary dependencies on kdebase4-workspace-devel and I've already removed them. So kdesdk4 builds directly after kdepimlibs4 and kdeutils4 is down to 6 hours, but still the winner. But the kdevplatform dependency on kdesdk4 was on kompare, and that's been "temporarily" disabled upstream for 3 months. So now kdeutils4 is at 5:30, matching kdepim4 and some other packages have a real dependency on kdebase4- workspace-devel and so they are stuck to be built after 5 hours. Another problem was a long KDE:Qt rebuild, and the aggregate in KKFD seems to stop being blocked only after all of KDE:Qt has been rebuilt (even packages that are actually not aggregated, for whatever reason). The most interesting problem in KDE:Qt is that the Qt libraries themselves, including WebKit, get rebuilt in every libqt4* package. Since things like qt- declarative had a dependency on libqt4-devel-doc, they needed to wait for double Qt rebuild. However, most of the libqt4-devel-doc dependencies were unnecessary, so I have removed them. Actually, the table above is not correct for the very initial state, this is after this fix, it originally took even longer. The table is for the current state, as qt-creator still has a build requirement on libqt4-devel-doc because of help generation tools. Now, that's all that has been already fixed in the repos. But I have more improvements under home:llunak:branches that I haven't committed to KDE:Qt/KKFD yet, as I'd like to get those okayed first. Changes in KDE:Qt should be moving the help generation tools from libqt4- devel-doc to libqt4-devel, where they IMO belong anyway, if apps need them for building documentation during their build. Second change should be making sure that Qt libs and WebKit are built only once. The trick is to install libqt4- devel (and libQtWebKit-devel) and symlinking them to the build dir's bin/ and lib/. It seems to work just fine. I additionally split off libqt4-webkit, in order to have libqt4-devel ready sooner for some further packages that don't require WebKit, although I'm not entirely sure it's worth it (most stuff requires WebKit anyway, and the aggregate blocks KKFD anyway). Changes in KKFD should be using final builds (i.e. KDE4_ENABLE_FINAL=1) for kdelibs4, kdepimlibs4 and kdebase4-workspace. These 3 are the biggest bottlenecks (maybe with python-kde4, but I think kdebindings4 is already troublesome enough). It needed some fixes (it seems nobody has been using that lately, maybe cmake's stupid dependency handling is to blame), but now it builds fine. Hopefully it's not a big deal to keep it that way (it's mostly just kde4_no_enable_final(<whatever>) in the subdir's CMakeLists.txt or just disabling it altogether for the package). Do you think it'd be worth it? We used to build KDE3 this way too. With all these changes, the final table should look like this: libqt4 0:30 (+0:30) -> libqt4-webkit 1:00 (+0:30) -> libqt4-devel-doc 1:20 (+0:20) -> automoc4, soprano, strigi, phonon 1:40 (+0:20) -> kdelibs4 2:00 (+0:20) -> kdepimlibs4 2:10 (+0:10) -> kdebase4-workspace 2:30 (+0:20) -> kdevplatform 2:30 (+0:20) -> python-kde4 3:15 (+0:45) -> kdeutils4 3:35 (+0:20) -> kdepim4-runtime 2:30 (+0:20) -> kdepim4 3:40 (+1:10) -> kdegraphics4 2:25 (+0:25) -> koffice2 4:15 (+1:50) The winner is now koffice2 with 4:15 hours, with no obvious dependency to improve, but it doesn't get updated together with KDE SC, so koffice2 doesn't matter that much. The rest should be under 4 hours total, 2:30 in KKFD alone. Comments, okays, cookies :) ? -- Lubos Lunak KDE developer -------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: l.lunak@suse.cz , l.lunak@kde.org Lihovarska 1060/12 tel: +420 284 028 972 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org