15:07:36 <jreznik> #startmeeting kde-sig -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2012-07-24
15:07:36 <zodbot> Meeting started Tue Jul 24 15:07:36 2012 UTC.  The chair is jreznik. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:07:36 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:07:43 <jreznik> #meetingname kde-sig
15:07:43 <zodbot> The meeting name has been set to 'kde-sig'
15:07:49 <jreznik> #topic roll call
15:07:58 * jreznik thinks he's here
15:08:13 * jgrulich is here
15:08:17 <Kevin_Kofler> Present.
15:09:26 * striker|rh watching.
15:09:41 * rnovacek is here
15:10:07 * ltinkl is here
15:11:45 <rdieter> yo
15:13:46 <jreznik> #topic Agenda
15:14:05 <jreznik> #info jreznik jgrulich Kevin_Kofler rnovacek ltinkl rdieter present
15:14:21 <Kevin_Kofler> mass rebuild aftermath
15:14:31 <jreznik> #chair jreznik jgrulich Kevin_Kofler rnovacek ltinkl rdieter
15:14:31 <zodbot> Current chairs: Kevin_Kofler jgrulich jreznik ltinkl rdieter rnovacek
15:16:06 <jreznik> do we have more for MiniDebugInfo?
15:16:42 <Kevin_Kofler> I wonder where we are size-wise now.
15:17:27 <Kevin_Kofler> But IMHO that's part of the "mass rebuild aftermath" topic.
15:17:52 <jreznik> Kevin_Kofler: yep, it is
15:17:57 <Kevin_Kofler> (The whole goal of the mass rebuild was to get MiniDebugInfo (and DwarfCompression) out to packages.)
15:18:05 <jreznik> Kevin_Kofler: indeed
15:18:13 <jreznik> #topic mass rebuild aftermath
15:18:36 <VICODAN> hello kde sig ;)
15:19:33 <jreznik> #link http://fedorapeople.org/~ausil/f18-failures.html
15:19:39 <jreznik> f18 rebuild failures
15:20:10 <Kevin_Kofler> I'm trying to figure out the size impact.
15:20:41 <Kevin_Kofler> But I can't check whether there are any daily/nightly live images with it because Koji is not responding (or too slowly).
15:21:05 <jreznik> #action kde siggers to take a look on the failing packages
15:21:40 <Kevin_Kofler> Re the build failures, they include the usual suspects: kdelibs3, klamav (ancient kdelibs3 app) etc.
15:21:53 <Kevin_Kofler> Looks like I'll have some work to keep things building again, grrr…
15:22:04 <rdieter> speaking of ftbfs, libgphoto2-2.5 induced ones:  digikam, kamera
15:22:41 * jreznik fixed qtcurve-kde4
15:22:55 <Kevin_Kofler> So Koji is responding now, all the recent live CD composes failed. :-/
15:23:04 <rdieter> jreznik: thx (i'd been hoping either kwin or qtcurve upstream would fix it, but :( )
15:23:06 <ltinkl> kamera has been fixed in kde git today
15:23:07 <jreznik> there's plasma-mobile - it needs probably rebase once we have 4.9
15:23:09 <Kevin_Kofler> So we don't know yet how bad the bloat is.
15:23:11 <ltinkl> I'll take care of that
15:23:17 <rdieter> ltinkl: woo, one down.
15:23:27 <jreznik> rdieter: it's actually qtcurve-kde4 upstream fix I've found at kde-look.org
15:23:28 <VICODAN> libgphoto2 completely broke rawhide for me last night
15:23:30 <jreznik> :)
15:23:30 <rdieter> jreznik: yes, nepomuk changes
15:23:32 <ltinkl> fixed = rather heavy ported :)
15:23:42 <Kevin_Kofler> kdelibs3 succeeded on x86_64 and failed on i686, WTF!
15:23:55 <ltinkl> digikam will be a bigger problem imho
15:24:04 <rdieter> Kevin_Kofler: I saw one like that too.
15:24:06 <VICODAN> could not install rawhide and had to remove libgphoto2
15:24:24 <jreznik> and I also have meego leftovers - libqttracker, is there any user? (me should try repoquery but I don't think so)
15:24:26 <rdieter> Kevin_Kofler: oh, right, qjson, getting wierd vtable errors on i686
15:24:57 <Kevin_Kofler> kdelibs3 has tons of syntax errors on i686, and not on x86_64 for some reason, huh?
15:25:30 <Kevin_Kofler> It's using a Perl script to generate the file, might be a parallel make race condition or even a Perl bug, ugh.
15:25:41 <Kevin_Kofler> Maybe the dumb "fix" (resubmit the build) is enough?
15:26:24 <jreznik> could be
15:26:25 <rdieter> Kevin_Kofler: I suppose turning off --enable-final may help too (or at least better highlight where the problem(s) are)
15:27:04 <rdieter> Kevin_Kofler: I'll resubmit for now, and we'll see
15:27:25 <rdieter> err, can't resubmit, but I'll queue a new one
15:27:58 <rdieter> http://koji.fedoraproject.org/koji/taskinfo?taskID=4325906
15:28:28 <Kevin_Kofler> Your kdepim3 compat package also failed, BTW.
15:28:35 <Kevin_Kofler> Let me check where.
15:29:27 <Kevin_Kofler> Ugh, DCOP kalyptus fail:
15:29:29 <Kevin_Kofler> BEGIN failed--compilation aborted at ../dcopidlng/kalyptusCxxToDcopIDL.pm line 29.
15:29:31 <Kevin_Kofler> Compilation failed in require at ../dcopidlng/kalyptus line 386.
15:29:46 <Kevin_Kofler> Do we still need kdepim3? It was done for Taskjuggler only, IIRC.
15:30:02 * jreznik is now TJ user...
15:30:06 <Kevin_Kofler> In any case, this seems to be in Perl stuff, too (but on x86_64).
15:30:10 <rdieter> still needed for taskjuggler
15:30:21 <jreznik> it should be possible to cut out TJ UI from package...
15:30:28 <Kevin_Kofler> Did Perl change recently, to cause these issues?
15:30:52 <jreznik> Kevin_Kofler: http://fedoraproject.org/wiki/Features/perl5.16
15:31:11 <Kevin_Kofler> jreznik: I already had a version of the old TJ where I disabled ICal support (which required kdepim3).
15:31:21 <Kevin_Kofler> People wanted the ICal support back at all costs and so kdepim3 was introduced.
15:31:37 <Kevin_Kofler> If we don't need the backend of TJ anymore, it might be worth resurrecting my old patch.
15:31:45 <Kevin_Kofler> (Must still be in dist-git somewhere.)
15:31:45 <jreznik> Kevin_Kofler: iCal is quite important...
15:32:15 <jreznik> well I have some patched version from Robyn, I'll take a look what's where (it's patched for iCal support)
15:32:22 <Kevin_Kofler> For kdepim3, I'd also suggest resubmitting the build to see whether the failure is reproducible.
15:33:04 <rnovacek> I've started to work on Qt4 version of TJ while ago, but it's a lot of work
15:33:10 <Kevin_Kofler> If it is, we need to look at the offending kalyptusCxxToDcopIDL.pm file.
15:34:25 <rnovacek> maybe jreznik can do a guinea pig once I have something that at least compile :)
15:35:05 <jreznik> rnovacek: actually it's nonsense as TJ changed completely - so Qt 4 UI on top of TJ3 would make sense, but TJ3 is not feature complete...
15:35:23 <Kevin_Kofler> Klamav is choking on gz* APIs ("error: cannot convert 'gzFile_s**' to 'gzFile' for argument '1' to 'int gzread(gzFile, voidp, unsigned int)'" and likewise for gzclose(gzFile) in several places).
15:36:01 <Kevin_Kofler> That's a code bug (library API change?) and I'll have to fix it.
15:36:27 <Kevin_Kofler> (It's my package, the original maintainer gave up long ago.)
15:36:36 <rnovacek> jreznik: did you try TJ3?
15:36:46 <Kevin_Kofler> (I already effectively fixed the package repeatedly back when it wasn't mine.)
15:37:54 <jreznik> rnovacek: yep, but there are still missing features we use for schedules...
15:38:17 <jreznik> otherwise it's 1:1 qt to ruby rewrite, don't understand why...
15:38:25 <jreznik> or sorry c++ to ruby
15:39:35 <rnovacek> jreznik: you might try to report this bugs/RFEs upstream so we might get rid of TJ2
15:39:58 <jreznik> rnovacek: it's my plan
15:40:06 <rnovacek> jreznik: awesome :)
15:40:34 <jreznik> usually nobody uses the gui on top of old TJ, we have Makefiles... but actually I like the gui - it's faster...
15:41:07 <Kevin_Kofler> Hmmm, is there a way to figure out whether an RPM includes MiniDebugInfo already or not? (I'd like to be sure I get the size impact right…)
15:42:27 <Kevin_Kofler> I see kdelibs-4.8.90-2.fc18 at 11309832 bytes (for the 32-bit main package), kdelibs-4.8.97-7.fc18 at 12068596 bytes, that's 700 KiB for kdelibs alone.
15:43:31 <Kevin_Kofler> But a global view can only really be made from the live image sizes, which I can't see now because the composes are failing, grrr…
15:44:50 <kalev> Kevin_Kofler: you should be able to do 'readelf -S yourelfbinary | grep .gnu_debugdata'. If there's the .gnu_debugdata, it has minidebuginfo enabled.
15:47:07 <Kevin_Kofler> So why is this embedded in the executable? I thought the proposal on the feature page was to have this in external files included in the main package? Though that'd have required RPM changes, of course…
15:47:49 <Kevin_Kofler> Anyway, how MiniDebugInfo is implemented is not a KDE SIG matter, I guess we'll have to deal with it as is.
15:48:32 <Kevin_Kofler> Thanks for the hint, though it's not very practical because I have to download the RPM and extract a binary to run readelf on it, I'd have hoped for something visible in the Koji package info page. :-(
15:49:10 <Kevin_Kofler> (That MiniDebugInfo "feature" is so badly thought through, it's really a PITA. :-( )
15:49:12 <rdieter> Kevin_Kofler: adding some rpm marker would've been nice.
15:50:11 <Kevin_Kofler> I really don't see why debugging info can't be in a subpackage as it always was. Forcing it on everyone just sucks.
15:50:57 <Kevin_Kofler> We can't even get rid of it from our spin without doing ugly things like running strip (or eu-strip) from the spin kickstart, which I obviously don't want to get into.
15:52:59 <Kevin_Kofler> Proposal: express an official KDE SIG position as follows: We are deeply saddened by the fact that FESCo approves features affecting the sizes of the live images in a critical way without giving any consideration to the objections of the images' maintainers, and our position is that the live image maintainers shall be given veto power over such features in the future.
15:53:04 <Kevin_Kofler> +1 from me obviously.
15:53:34 <Kevin_Kofler> (FWIW, this also hits OLPC, not just us.)
15:53:38 <VICODAN> +1 to that
15:53:52 <Kevin_Kofler> (FESCo refused to reconsider even after this was pointed out to them.)
15:58:18 <jreznik> Kevin_Kofler: I'm +1 too...
15:59:08 <Kevin_Kofler> I also don't like how the answer to "this will make us fail our size target" was "then just pick a bigger one". :-/
15:59:35 <Kevin_Kofler> This kind of tacit approval of bloat is a step in the wrong direction.
16:00:32 <Kevin_Kofler> We worked hard to stick to CD size, getting told "from above" that CDs suck and we just need to accept to target something bigger is really frustrating.
16:01:28 <Kevin_Kofler> It's all the more ridiculous as on the other hand, the same FESCo wants to make a heavily size-constrained architecture a primary architecture.
16:02:57 <jreznik> we are over time - anybody else wants to vote on proposal? ltinkl rdieter etc..
16:03:12 <ltinkl> +1 from me, obviously :)
16:03:32 <jgrulich> +1
16:05:36 <jreznik> rdieter: ?
16:07:00 <jreznik> we have 4 +1, do you want to send it to FESCo?
16:07:19 <jreznik> but I'd still like to see rdieter opinion on this
16:07:41 <rdieter> sorry got pulled away
16:08:26 <rdieter> personally, I don't think that proposal has any possible constructive outcome as stated so, -1
16:09:19 <rdieter> we'd already agreed to increase our spin size, so it's not as though it's crippling us... is it?
16:10:16 <rdieter> i mean, if it impacted us in some blocker-worthy way, I might feel differently
16:10:43 <Kevin_Kofler> We still don't have any idea about what the size will be, the nightly composes are all failing. :-/
16:10:53 <Kevin_Kofler> (no idea why)
16:11:03 <Kevin_Kofler> (probably not related to MiniDebugInfo)
16:11:25 <rdieter> when/if there's real problems, let's deal with it then, imo, not before
16:12:04 <Kevin_Kofler> The thing is, we only grudgingly "agreed" to increase our spin size because FESCo basically told us to do so. :-/
16:12:09 <rdieter> but seems i may be in the minority here, if the rest of you feel otherwise, go ahead
16:12:12 <Kevin_Kofler> Their attitude in all this was really unhelpful.
16:12:33 <Kevin_Kofler> They ignored even OLPC who cannot just increase their target size, the XO 1.0 has only so much FlashROM.
16:12:40 * rdieter didn't grudgingly agree, Kevin_Kofler did apparently  :)
16:12:56 <Kevin_Kofler> You've been pushing for it all the time, but you were the only one. ;-)
16:13:11 <jreznik> well, let's postpone it once we have arguments - data, how big it was...
16:13:30 <Kevin_Kofler> Yeah, let's check back once we actually have images that compose. :-/
16:15:31 <jreznik> ok
16:16:00 * jreznik was bad meeting leader - nearly no infos/actions... he'll try to go through the log to prepare some...
16:16:11 <jreznik> we are over time, I'm going to close the meeting
16:17:41 <jreznik> #endmeeting