15:04:09 #startmeeting kde-sig -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2011-06-07 15:04:09 Meeting started Tue Jun 7 15:04:09 2011 UTC. The chair is jreznik. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:04:09 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:04:21 #meetingname kde-sig 15:04:21 The meeting name has been set to 'kde-sig' 15:04:32 #topic roll call 15:04:37 Present. 15:04:38 who's present today? 15:04:45 * rnovacek is here 15:04:49 * jsmith lurks 15:05:55 yo 15:06:17 present 15:06:58 #info jreznik Kevin_Kofler rnovacek rdieter_work than_home present, jsmith lurks ;-) 15:07:08 #chair Kevin_Kofler rnovacek rdieter_work than_home 15:07:08 Current chairs: Kevin_Kofler jreznik rdieter_work rnovacek than_home 15:07:26 #topic Agenda 15:07:56 4.7 packaging 15:08:01 This Qt patch: https://bugzilla.redhat.com/show_bug.cgi?id=705348#c24 15:08:36 jreznik: I'm also lurking 15:08:57 4.6.4 packaging added 15:09:08 zaniyah: ;-) 15:09:28 anything else? a lot of stuff and I expect hot discussion :) 15:09:35 so let's start 15:09:50 easier one 15:09:55 #topic 4.6.4 status 15:10:15 That one should be fairly straightforward. 15:10:16 than_home already started to work on 4.6.4, what's the status? 15:10:25 Only possible painpoint: kdeedu is missing some .cmake files. 15:10:37 So stuff building against kdeedu-devel, if any, might have trouble. 15:11:00 If we're missing files, we'll have to add them from the 4.6.3 tarball. 15:11:14 But by itself it's reported to build. 15:11:15 kde-4.6.4 was commited in fedora git 15:11:44 kdelibs, kdebase*, kde-l10n were built 15:12:04 the rest are still building 15:12:18 * rdieter_work just re-enabled dist-f14-kde koji target 15:12:26 #info kde 4.6.4 commited to fedora git, kdelibs, kdebase*, kde-l10n are already built 15:12:40 #action rdieter_work to re-enable dist-f14-kde koji target 15:13:00 #info Kevin_Kofler reports missing some .cmake files in kdeedu 15:13:09 (That was reported on kde-packager.) 15:13:24 someone should take a closer look on it 15:13:31 Kevin_Kofler: do you mean kdeedu-4.6.4? 15:13:52 Yes. 15:14:08 It's now built from the git 4.6 branch, it used to be built from SVN. 15:14:35 (They tried to build 4.6.3 from git and there were many issues, so they just used the last SVN revision. Now the git stuff is sorted out.) 15:14:44 ok, i will take a look at this 15:14:56 (but there was that report about .cmake files) 15:15:07 #action than_home to take a look at 4.6.4 kdeedu issues 15:15:39 anything else regarding 4.6.4? 15:16:34 When we file the updates, we should mark https://bugzilla.redhat.com/show_bug.cgi?id=509645 as fixed. 15:16:48 (unless we push my 4.6.3 builds with the fix first) 15:17:29 See also https://git.reviewboard.kde.org/r/101513/ 15:17:40 Kevin_Kofler: please remind us if we forget ;-) 15:18:20 #info rhbz#509645 should be marked as fixed in 4.6.4 update (if not pushed as 4.6.3 one) 15:18:32 * thomasj is as well here 15:19:53 ok, let's move 15:20:18 #topic 4.6.80 aka 4.7 beta 1 packaging status 15:20:33 as you all know, 4.6.80 is a mess... 15:21:11 currently kdelibs, kdebase* and some other packages are built 15:21:34 #info currently kdelibs, kdebase* and some other packages are built 15:21:51 So I think we should finish building things in the current structure. 15:21:57 Quite some stuff is not split anyway. 15:22:01 Let's start with that. 15:22:03 so the base splitted packages are now multisource hacked... 15:22:25 Kevin_Kofler: yep, now the question is how to finish kdeedu, kdegraphics and kdebindings 15:22:37 But I think it should be possible to get kdeedu and kdegraphics going at least, kdebindings is missing pieces so that one is going to be the worst mess. 15:22:57 I started creating new packages for kdeedu apps 15:23:03 I tend to agree with Kevin_Kofler, even it's more work - to finish it with current structure and the slowly start splitting (package reviews etc) 15:23:05 kdebindings is always broken. 15:23:12 jreznik: we have clear state for kdeedu now, we follow the kde upstream splittings 15:23:18 Actually, my plan is to not split at all. 15:23:35 I actually want to undo the kdeedu-math split for which the use case went away eons ago. 15:23:36 Kevin_Kofler: that's another question, let's fight current situation 15:23:45 (and just merge it into kdeedu and Obsoletes: kdeedu-math there) 15:24:04 I think splitting is cleaner solution for kdeedu 15:24:32 those apps are independent (most of them even don't depend on libkdeedu) 15:24:34 If you think doing all those reviews can be done in time for Fedora 16… 15:24:36 kdeedu splits are final, annma proved that today 15:25:00 Well, there's also the release-team which has a say in what gets released… 15:25:12 * rdieter_work thinks we should follow upstream splits with kdeedu as a test-case 15:25:13 The kdeedu developers don't necessarily have the final word. 15:25:15 Kevin_Kofler: it can be done but it will take some time, so I'd like to have kdeedu in monolithic package too 15:25:35 see how it goes, possibly follow suit with kdegraphics, kdebindings too 15:25:38 I put specfiles for kdeedu apps here: http://fedoraproject.org/wiki/SIGs/KDE/KDE47Packaging#kdeedu 15:25:48 few of them so far 15:25:51 Too bad it's only Eric and me fighting the crowd. :-( 15:27:00 Doing split SRPMs also means more buildtime dependencies to deal with. 15:27:08 (i.e. building libkdeedu before the rest) 15:27:16 Kevin_Kofler: yes, it means... 15:27:18 besides Kevin_Kofler, whose opinion is fairly clear, anyone else object to packaging split kdeedu ? 15:27:20 And also verifying the BRs for each single package. 15:27:29 And issuing many more builds at each update. 15:27:34 for us as packagers - it's more difficult 15:28:01 the real question is if we want to follow our policy to stick as close to upstream 15:28:13 And also polluting the update metadata (because there's at least one binary package per SRPM). 15:28:44 jreznik: We have some unsplit packages of modular upstreams in Fedora already! 15:28:50 See e.g. xorg-x11-apps or how it's called. 15:29:12 Kevin_Kofler: I'm talking about our packages 15:29:14 Yes, that's the name. 15:29:16 http://pkgs.fedoraproject.org/gitweb/?p=xorg-x11-apps.git;a=blob;f=xorg-x11-apps.spec;h=b16da448804957111d7a1d3871a54cde201d4327;hb=HEAD 15:29:24 we used upstream as excuse not to split 15:29:29 There are 21 source tarballs in there. 15:29:49 no when they split we are arguing oposite way... :) 15:30:15 X.Org also has split tarballs and the Fedora packaging is not always split. 15:30:38 In our packaging, there's kde-l10n and kde-i18n, which have split binary packages, but unsplit source packages. 15:30:44 And of course the Marble 1.1 hack. 15:31:01 (xorg-x11-apps is entirely unsplit, no subpackage at all.) 15:31:09 Announcement from my owner (jsmith): Fedora Board public IRC meeting in approximately 30 minutes in #fedora-board-meeting 15:31:11 Now when upstream splitted packages most distros will split too 15:31:20 * rdieter_work doesn't think providing examples of non-split packages should influence this decision either way, imo 15:31:30 and then more users will ask us to split 15:31:40 Most distros already split stuff. 15:31:42 rnovacek: that too, +1 15:32:43 Representative line of xorg-x11-apps.spec: for app in * ; do 15:33:58 * jreznik tends to stay with current structure at least for 4.7, then try what can we do with kdeedu for F16... 15:34:29 for example - it makes sense for kdeedu as it's a big package of unrelated education apps... 15:34:57 * Kevin_Kofler suggests a kde-sc package with everything. ;-) 15:35:13 (Well, not seriously, but it'd be better than the opposite extreme. ^^) 15:37:16 But I don't think this discussion is going anywhere. 15:37:40 Kevin_Kofler: looks like you're the only one against, I'm somewhere in the middle 15:38:03 * jreznik understands more work for us but also sees an advantage for users... 15:39:24 Let's move on… 15:39:54 so the decision? 15:40:21 jreznik: we follow the kde upstream splitting 15:40:26 stick with current schema and split for f16? 15:40:39 split for f16 15:40:42 rnovacek: it's for f16 now in rawhide 15:41:03 I guess the idea is that we try both approaches for now to see what gets ready ASAP, but target splitting for this release cycle (i.e. F16). 15:41:13 but f15 is gonna get 4.7 too, right? 15:41:15 (i.e. split ASAP, since everyone except me wants it) 15:41:49 You'll see the mess you're creating. ;-) 15:42:00 rnovacek: what to do wrt f15/kde47 is a bit unknown at this point, considering the significant change in packaging 15:42:12 (but I blame upstream most of all) 15:42:15 rnovacek: I'm not sure I'll vote for that - it depends on the mess created 15:42:36 rnovacek: with splitting it's not easy for update in f15 15:42:41 and that's why I propose - let's to first classic kdeedu, graphics, bindings 15:42:48 That's another argument for not splitting at all! 15:43:23 then let's play with splitting... but that really means no update of splitted version for older releases 15:43:23 Kevin_Kofler: that's a bit extreme, with the same logic we'd never backport anything that involved packaging changes 15:43:56 but, change could be mitigated with prudent metapackaging 15:44:04 Kevin_Kofler: we will have same problems if we splitt it in the future 15:44:23 That's why I said "not at all", i.e. never… 15:44:43 it's better to change it now for f16 15:44:57 Kevin_Kofler: those packages will become hardly maintainable. What if separate releases (like Marble) will hapen more often? 15:45:24 xorg-x11-apps (and a few other packages like that) manage that kind of mess just fine. 15:45:49 If we're already hacking together multiple tarballs, doing a kdeedu build with a newer Marble hacked in will be even easier. 15:45:58 It was already not that hard to do 4.6.2-2. 15:46:04 * rdieter_work doesn't think anyone's going to change their minds with ongoing discussion, and repeated arguments 15:46:53 I've done worse hacks, like packaging koffice-kivio to coexist with KOffice 2. 15:47:15 (Hopefully Calligra Flow will let me retire that mess…) 15:48:35 But I think rdieter_work is right, we should move on. 15:49:22 ok, let's move 15:49:44 #topic Lohit fonts accidentally disable the bytecode interpreter for Qt [patch] 15:49:57 .bug 705348 15:49:59 jreznik: Bug 705348 Lohit fonts accidentally disable the bytecode interpreter for Qt - https://bugzilla.redhat.com/show_bug.cgi?id=705348 15:51:02 i will rebuilt qt with the patch soon so we can test 15:51:07 So Behdad provided a patch to Qt's fontconfig code which should fix this mess once and for all: https://bugzilla.redhat.com/show_bug.cgi?id=705348#c24 15:51:17 than_home: Great, please do. 15:52:09 #info Behdad provided a patch to Qt's fontconfig code 15:52:44 #action than_home to rebuild Qt with the patch soon to test 15:53:15 kudos to behdad and his font-fu 15:54:23 based on his comments, qt's fontconfig/freetype related code was a bit on the sad side, a little surprising it's worked as well as it has for so long. 15:55:30 Hardly anything used fontconfig settings before the new BCI vs. autohint tradeoffs. 15:55:51 (per-font settings, in particular) 15:56:08 good point, ie, no one ever noticed.... till now. 15:57:09 anything else for today, else, jreznik and I have a #fedora-board-meeting to run to here in a few minutes. 15:57:28 It's all from me… 15:58:29 ok, thanks guy 15:58:44 I'll prepare summary after board meeting 15:58:49 #endmeeting