15:03:11 <rdieter> #startmeeting kde-sig -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2012-03-06
15:03:11 <zodbot> Meeting started Tue Mar  6 15:03:11 2012 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:11 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:03:15 <rdieter> hi all
15:03:18 <rdieter> #topic roll call
15:03:24 <rdieter> who's present today?
15:03:28 * rnovacek is here
15:03:39 <Kevin_Kofler> Present.
15:04:01 <ltinkl> present
15:04:31 <rdieter> than: ping
15:04:40 * than is present
15:04:46 <rdieter> #info rdieter rnovacek  Kevin_Kofler ltinkl than present
15:04:48 <rnovacek> jreznik gives some talk at universities, so he probably won't make it
15:04:53 <rdieter> #chair rnovacek  Kevin_Kofler ltinkl than
15:04:53 <zodbot> Current chairs: Kevin_Kofler ltinkl rdieter rnovacek than
15:05:14 <rdieter> #info jreznik regards, giving talk at universities
15:05:20 <rdieter> rnovacek: nice :)
15:05:24 <rdieter> #topic agenda
15:05:36 <rdieter> I threw kde-4.8.1 on agenda, of course.  anything else for today?
15:06:19 <Kevin_Kofler> firstboot theming issue
15:06:45 <rdieter> Kevin_Kofler: is there really anything to discuss?  I'm not sure there's anything we can do about it, is there?
15:07:01 <rnovacek> plasma active status update
15:07:20 <Kevin_Kofler> rdieter: I can think of at least 2 solutions, can we discuss them when we get to the meeting item?
15:07:38 <rdieter> ok
15:08:19 * rdieter added those 2
15:08:28 <rdieter> let's get started then
15:08:32 <rdieter> #topic kde-4.8.1 status
15:09:02 <rdieter> rnovacek: you were helping out a bit, is rawhide import all done yet?
15:09:05 <rnovacek> I think we're done for f18/rawhide
15:09:10 <rdieter> yay
15:09:27 <rdieter> #info kde-4.8.1 import into rawhide complete
15:10:12 <rdieter> and f17 builds are started, I count 17 builds done so far
15:10:46 <rdieter> I (ab)used f17-kde target for a few other related items like soprano/redland and sip/PyQt4 updates too
15:11:28 <rdieter> so, any interested party(s) want to work on the remaining f17 builds ?
15:11:45 <rnovacek> I can continue on f17 builds tomorrow
15:11:48 <rdieter> oh, and saw a good kdepim patch fly by recently on kde-pacakger list, we probably out to import that too
15:12:06 <rdieter> #info rnovacek volunteers to work more on f17 builds starting tomorrow
15:12:19 <rdieter> thanks, I might to a little myself today too, if time allows
15:12:46 <than> i can take care of kdepim patches
15:12:48 <rdieter> #info jreznik volunteered previously to help do f16 backport/merge
15:13:10 <rdieter> hrm, I should've marked those action items oh well
15:13:36 <rdieter> #action than will import kdepim maildir patches from kde-packager list
15:13:58 <rdieter> anything else 4.8.1-wise
15:14:00 <rdieter> ?
15:14:00 <Kevin_Kofler> Yeah, fixing memory leaks is always a good idea.
15:14:23 <rdieter> agreed, probably a major factor in kmail1 migration failures
15:14:46 <Kevin_Kofler> There's that regression in KOrganizer reminders, which sadly was reported only yesterday. :-(
15:15:04 <Kevin_Kofler> Not sure we can do anything about it right now.
15:15:13 <rdieter> true, frankly though, I'm a little surprised that ever worked.
15:16:25 <rdieter> ok, moving on
15:16:32 <rdieter> #topic plasma-active status
15:16:39 <rdieter> rnovacek: ?
15:17:00 <rnovacek> I took a look at those patches
15:17:12 <rnovacek> here is my notes: http://fpaste.org/i7sH/
15:17:56 <rnovacek> one of main issues are different build options for kwin in plasma-active
15:18:12 <rnovacek> they disable window decorations for instance
15:18:31 <rdieter> eww
15:19:43 <rnovacek> this should be adjustable run time instead of build time
15:19:43 <rdieter> I'm going to guess we don't want that either. :)
15:20:05 <rdieter> agreed
15:20:13 <rnovacek> yes, it makes no sense on desktop
15:20:18 <Kevin_Kofler> They really need to use some runtime tweak for that.
15:20:32 <Kevin_Kofler> Also, exposing private Qt classes is a completely broken ugly hack.
15:20:37 <rnovacek> plasma active has all windows maximized
15:20:48 <Kevin_Kofler> (that privatepackageaccess crack)
15:20:50 <rdieter> these are obviously (hopefully) short-term hacks until things can be done properly
15:21:09 <Kevin_Kofler> rnovacek: They need code to disable the windecos at runtime.
15:21:15 <rdieter> but certainly doesn't make our life any simpler
15:21:24 <Kevin_Kofler> It's very possible to do this at runtime.
15:21:35 <Kevin_Kofler> Disabling the windecos at build time is a horrible solution.
15:21:52 <Kevin_Kofler> If we need it, I can probably write some custom code to do this at runtime.
15:22:50 <Kevin_Kofler> It can't be any worse of a hack than exposing private Qt classes. ^^
15:23:18 <rdieter> rnovacek: thanks for the review and summary.
15:23:24 <rnovacek> np
15:23:32 <rdieter> so of all of those, I see at least one, kde-workspace-ksmserver-qmf_shutdowndlg.diff , that we may want, right?
15:24:08 <rnovacek> rdieter: it depends if it has all the features of current solution
15:24:28 <rdieter> true, maybe safer just to skip that one too for now
15:24:54 <rdieter> besides that one, then, I don't see any other work to add/remove patches
15:24:58 * jreznik_n9__ is late from fedora roadshow, right after my kde/qt talk
15:25:09 <rdieter> jreznik_n9__: hi!
15:25:12 <Kevin_Kofler> I don't think there's any point in backporting the shutdown dialog backport.
15:25:21 <rnovacek> yes, I would go with skipping those we are not sure about and add them later if needed
15:25:25 <Kevin_Kofler> AIUI it looks pretty much the same, doesn't it?
15:25:47 <jreznik_n9__> yes
15:25:51 <rdieter> jreznik_n9__: rnovacek just reviewed plasma-active patches, notes http://fpaste.org/i7sH/
15:26:13 <rnovacek> I think current shutdown dialog is touch friendly enough
15:26:21 <rdieter> and it looks like we already have stuff we want/need, and no additional mods are required for now
15:27:05 <jreznik_n9__> rdieter, rnovacek: great, I'll check it with Radek, now in roaming from Slovakia
15:27:07 <Kevin_Kofler> For that windeco stuff, do we end up with window decorations shown in Active where they don't belong? I can see if I can write some code in Plasma Active to hide the windecos.
15:27:26 <jreznik_n9__> we have to hide it
15:27:47 <rnovacek> Kevin_Kofler: yes, now windows have decorations in Active
15:27:58 <rdieter> Kevin_Kofler: right, I'm more than a little surprised the active folks didn't do it that way (at runtime)
15:28:04 <jreznik_n9__> I expect it's in contour settings, we do not package it
15:28:12 <Kevin_Kofler> We need to figure out where the code which maximizes the windows is and hide the windecos there.
15:28:23 <Kevin_Kofler> jreznik_n9__: rnovacek said they do it at build time.
15:28:30 <Kevin_Kofler> (They disable windecos completely.)
15:28:36 <Kevin_Kofler> rdieter: Efficiency.
15:28:52 <Kevin_Kofler> They build KWin without windeco support so they don't have to load any windeco code at all.
15:28:58 <Kevin_Kofler> Of course that's a no go for us.
15:29:17 <rnovacek> jreznik_n9__: there is switch in CMake for that
15:29:20 <rnovacek> OPTION(KWIN_PLASMA_ACTIVE "Enable building KWin for Plasma Active." On)
15:29:36 <rdieter> ok.
15:29:50 <jreznik_n9__> ah
15:29:52 <Kevin_Kofler> I'll have a look at what goes on there and see if I can add some custom hacks for us there.
15:30:07 <rnovacek> and then they disable a lot of stuff: windeco, tilling, tabbing ect
15:30:18 <Kevin_Kofler> Probably add runtime if (something) to all the #ifdefs, just need to figure out what "something" to use (environment variable or whatever).
15:30:29 <rdieter> #action Kevin_Kofler to look into disabling windeco at runtime (instead of buildtime) for plasma-active
15:30:35 <jreznik_n9__> what about fake zero theme?
15:30:48 <rdieter> jreznik_n9__: I was thinking that too
15:30:54 <rdieter> evil, but may work. :)
15:31:03 <rnovacek> jreznik_n9__: comes to my mind too...
15:31:03 <Kevin_Kofler> That won't help the other stuff they disable.
15:31:08 <rdieter> true
15:31:12 <Kevin_Kofler> Unless we want to keep that stuff enabled…
15:31:13 * jreznik_n9__ is evil...
15:31:28 <rnovacek> we also need all windows to be maximized
15:31:30 <Kevin_Kofler> I'll have a look at the code to see what kind of a mess it is.
15:31:37 <jreznik_n9__> what else they disable?
15:31:39 <rdieter> Kevin_Kofler: thanks.
15:31:51 <rdieter> jreznik_n9__: rnovacek mentioned tiling, tabbing too
15:32:43 <rnovacek> jreznik_n9__: this is part of cmake for kwin http://fpaste.org/nNrj/
15:32:45 <Kevin_Kofler> Another option might be to build KWin separately, but then we'll have 4 KWins (normal, normal+GLES, Active (normal GL), Active+GLES)…
15:33:31 <Kevin_Kofler> Could be evil and only support desktop with desktop GL and Active with GLES, but some people will kill us for that, there are definitely some people who want GLES for desktop.
15:33:40 * rdieter doubts active/normalGL would be neeed, but that still leaves 3
15:34:04 <rdieter> Kevin_Kofler: agreed
15:34:25 <jreznik_n9__> gles should be the only one for active
15:34:33 <rdieter> oh well, look into it, and poke upstream to see if we can get a little more sanity here.
15:34:38 <Kevin_Kofler> I'm sure there will be SOMEBODY who'll want to run Active on NVidia…
15:34:46 <rdieter> then we can evaluate and decide what else to do
15:35:06 <rdieter> anything else to discuss on this topic?  I'll move on in a bit if not.
15:35:14 <Kevin_Kofler> But whatever, I guess we can build a custom kwin_gles_active or something and patch startactive to use that.
15:35:28 <jreznik_n9__> ok
15:35:32 <Kevin_Kofler> I think it's probably the easiest solution, seeing how many CMake variables KWIN_PLASMA_ACTIVE touches.
15:35:49 <Kevin_Kofler> (I'd have hoped the code would use KWIN_PLASMA_ACTIVE directly, rather than a bazillion other stuff… :-/ )
15:36:08 <rnovacek> Kevin_Kofler: +1, seem like best solution for now
15:36:43 <Kevin_Kofler> I'll see what specfile and/or CMakeLists.txt hackery is needed to get that going.
15:36:44 <jreznik_n9__> upstream cares more about spark os now
15:36:51 <Kevin_Kofler> s/more/only/ :-/
15:37:03 <Kevin_Kofler> They don't give a darn about Plasma Active on normal distros.
15:37:12 <Kevin_Kofler> They think Active is a separate world.
15:37:18 <jreznik_n9__> -1
15:37:29 <Kevin_Kofler> They actively discourage shipping Active in general-purpose distros.
15:38:13 <rdieter> I take issue with that assertion, but regardless, I think we ought to help remove any such attitudes
15:38:21 <Kevin_Kofler> They don't understand that stuff like Fedora ARM builds from normal Fedora repos.
15:38:40 <rdieter> right, if they don't understand, we need to help make them understand
15:39:00 <Kevin_Kofler> rdieter: At least one upstream developer outright told me that shipping Plasma Active and Plasma Desktop in the same distro is something they don't support.
15:39:08 <rdieter> who?
15:39:11 <Kevin_Kofler> (in the context of patches Active does to core packages)
15:39:23 <Kevin_Kofler> I think it was Aaron, but I'm not sure, might have been somebody else.
15:39:37 <rdieter> they might not like or support that *now*, but they need to understand that's a pretty unreasonable position to take.
15:39:49 <rdieter> imnsho yada yada
15:40:27 <rdieter> anyway, we're off in the weeds now
15:40:33 <jreznik_n9__> that's the problem we need everything in one repo, it's not anissue for some generic purpose distros
15:40:53 <Kevin_Kofler> They said the Plasma Active patches are all totally untested on desktops and thus not supported, and since some of them are needed, they don't support the mix.
15:41:10 <jreznik_n9__> but let's help fixing that
15:41:15 <rdieter> jreznik_n9__: +1
15:41:28 <rdieter> let's move on, *talking* here won't help or change anything
15:41:45 <rdieter> #topic firstboot theming
15:41:49 <jreznik_n9__> +1
15:41:49 <rdieter> Kevin_Kofler: you had some ideas?
15:42:07 <Kevin_Kofler> So I see 3 solutions for the firstboot problem:
15:42:09 <Kevin_Kofler> Solution 1: go back to setting the GTK+ theme (at least the GTK+ 2 one) for root in /root/.gtk-2.0/gtkrc to oxygen-gtk as we used to do in the past. Drawback: affects apps running as root in other desktops.
15:42:10 <jreznik_n9__> replace first boot?
15:42:11 <Kevin_Kofler> Solution 2: pull in adwaita-gtk2-theme into the spin. Drawbacks: consumes space, is not Oxygen (but better than the default ugly theme).
15:42:12 <Kevin_Kofler> Solution 3: add some code to firstboot to detect that it's running on a KDE spin (e.g. "adwaita-gtk2-theme is not present and xsettings-kde is") and run xsettings-kde. Drawback: The Anaconda people probably won't like the hackery in their code.
15:43:02 <Kevin_Kofler> I'd vote for 1, it's what we've done for a while, I only removed the code because I had hoped xsettings-kde would make it not needed, but I had forgotten about firstboot. :-(
15:43:05 * rdieter ponders pros/cons, thinks option 2 is likely the best and easiest fit for now
15:43:26 <rdieter> option 1 is doable too I guess, ok.
15:43:51 <Kevin_Kofler> We can do 2 if we have the space, should be 1 line in the kickstart (+ 1 line of comment to explain why).
15:44:00 <jreznik_n9__> i try to talk to firstboot developer
15:44:07 <rdieter> anyone else have an opinion ?
15:44:12 <Kevin_Kofler> Won't have the Oxygen look, but then again firstboot is not KDE.
15:44:25 <Kevin_Kofler> I think 2 might actually be the saner solution.
15:44:30 <rdieter> jreznik_n9__: ok, report back what they think
15:44:41 <jreznik_n9__> to add 3 to firstboot
15:45:03 <rdieter> #action jreznik_n9__ to discuss theming issues with firstboot devs
15:45:08 <jreznik_n9__> ok
15:45:12 <Kevin_Kofler> So I'm torn between 1 and 2 as a quick hack, I like 3 in theory but I'm not sure about what to do about it in practice.
15:45:28 <rdieter> Kevin_Kofler: +1, me too
15:45:55 <rdieter> we can judge once we have more info from jreznik_n9__'s chat with dev's
15:46:09 <rdieter> #topic open discussion
15:46:14 <rdieter> anything else for today?
15:46:24 <Kevin_Kofler> I don't want to add funky code to firstboot without their consent, they might see it as ugly and hackish.
15:46:34 <nucleo> making release of live DVD and CD
15:46:41 <Kevin_Kofler> (and thus as an abuse of provenpackager privileges)
15:46:48 <rdieter> nucleo: ah, thanks.
15:46:52 <Kevin_Kofler> nucleo: -1
15:46:59 <Kevin_Kofler> rel-eng won't do both, and the CD is large enough.
15:47:16 <Kevin_Kofler> The latest status is that we can probably fit Amarok again now that comps is cleaned up.
15:47:18 <jreznik_n9__> could you recap beginning of meeting for me?
15:47:24 <rdieter> Kevin_Kofler: rel-eng has never said they wouldn't do it, have they?
15:47:36 <rdieter> jreznik_n9__: begging topic was kde-4.8.1 status
15:47:54 <rdieter> rawhide done, f17 started (i'll do some work today, rnovacek tomorrow).
15:48:11 <rdieter> jreznik_n9__: and then f16 work to be lead by you. :)
15:48:14 <Kevin_Kofler> We'll know more once Calligra is finally pushed to stable (and composes thus work again), but last I checked we're fitting.
15:48:15 <nucleo> if science DVD released why DVD with KDE can't?
15:48:44 <Kevin_Kofler> Scientific is more than just a larger version of the KDE spin.
15:48:52 <rdieter> Kevin_Kofler: so let's take rel-eng out of the discussion for now.   what do *we* want?
15:48:58 <Kevin_Kofler> It has a specific purpose.
15:49:22 <rdieter> any thoughts about making a bigger ~1gb (or more) kde live dvd again?
15:49:38 <Kevin_Kofler> At the expense of the CD? -1
15:49:47 <rdieter> No, not at any expense
15:49:57 <rdieter> assume kde live cd is a given.
15:49:57 <jreznik_n9__> rdieter, anyone finished f17, I was traveling from the early meeting
15:50:03 <Kevin_Kofler> (All the other desktops fit on a CD, we don't want to be the only large one.)
15:50:23 <Kevin_Kofler> DVD as an additional option, maybe (but I doubt they'll like the idea).
15:50:25 <rdieter> so yeah, one downside is the multidesktop DVD
15:50:36 <Kevin_Kofler> I don't see a concrete need for it.
15:50:50 <rdieter> if say, for f18 we chose to be live dvd only, we'd no longer fit
15:50:52 <Kevin_Kofler> It looks like we can fit almost everything we want on the CD again.
15:51:30 <rdieter> Kevin_Kofler: there's a lot more I'd like in a perfect world
15:51:32 <Kevin_Kofler> As I said, we had composes with Amarok on it and room to spare, I'll check the latest status once Calligra is finally pushed to stable.
15:51:37 <rdieter> but as-is, it's not *bad*
15:51:50 <Kevin_Kofler> Such as? When I asked for ideas for the DVD version, we couldn't think of almost anything!
15:52:04 <rdieter> is marble on the live image?  I didn't think it was?
15:52:16 <Kevin_Kofler> I ended up pulling in all the Cantor backends including R just to fill up some space. :-)
15:52:32 <rdieter> marble on cd live that is...?
15:52:42 <Kevin_Kofler> That's right, the Digikam / kipi-plugins / Marble cluster is missing on the CD.
15:53:00 <rdieter> that's my main gripe, marble, kipi-plugins, digikam
15:53:04 <Kevin_Kofler> (I say cluster because both Digikam and kipi-plugins require Marble, and Digikam and kipi-plugins are best shipped together.)
15:53:41 <Kevin_Kofler> I need to check where we are space-wise right now, but I suspect even Marble alone likely will be too large. :-(
15:54:24 <rdieter> it almost certainly is, it's pretty big
15:54:37 <Kevin_Kofler> (It so sucks that SELinux gets forced on us by the central powers, removing selinux-policy would free a lot of space!)
15:54:45 <rdieter> nucleo: so, I take it rel-eng is no longer producing 1gb daily images either/
15:54:47 <rdieter> ?
15:55:06 <Kevin_Kofler> rdieter: They are producing them, but they've been failing since forever due to broken deps in Krita.
15:55:14 <Kevin_Kofler> They should be fixed when Calligra finally lands.
15:55:16 <rdieter> oh, nevermind then
15:55:28 <Kevin_Kofler> It's already Tuesday and still no stable push, grrr…
15:55:38 <Kevin_Kofler> They did a testing push, but no stable push, I hate when they do that.
15:55:41 <rdieter> nucleo: so, what are you asking for then?  asking that the bigger image be released and mirrored?
15:55:59 <nucleo> so will be no 1G live image at all?
15:56:29 <rdieter> daily images are being produced, but we've not asked for it to be considered part of any GA release
15:56:41 <rdieter> so I take it, the question is should we?
15:57:01 <nucleo> 1g image can be distributed in the same way as other spins like Scientific
15:57:39 <rdieter> and if we choose to do that, make efforts to avoid confusion, and clearly document what it is, and how it differs from livecd
15:57:42 <Kevin_Kofler> So the March 1 daily came at 679 MiB, but was missing the Telepathy stuff. There has been no working daily image since because first no daily images were done, and then I updated the live kickstart for Calligra which is already queued for stable, but no stable pushes were done, grrr!
15:58:18 * jreznik_n9__ has to quit now
15:58:32 <Kevin_Kofler> The larger version hasn't composed for ages (broken Krita deps), but last I checked it was around 1½ GiB.
15:58:40 <nucleo> place only 1g image on http://spins.fedoraproject.org/
15:58:40 <Kevin_Kofler> There is no kickstart with exactly 1 GiB.
15:58:43 <rdieter> nirik: ping, if you have a moment, any hint/estimate when next f17/stable updates push will happen?
15:59:10 <rdieter> (all our kde live image dailies are failing until that happens)
15:59:12 <nucleo> CD will be available on fedoraproject.org download page
15:59:12 <nirik> rdieter: going to be one this morning and dgilmore is going to run another branched compose.
15:59:22 <rdieter> nirik: yay, thanks.
15:59:25 <nirik> so hopefully something will land later today.
15:59:28 <Kevin_Kofler> OK
15:59:29 <nirik> if not, then tomorrow.
15:59:51 <rdieter> Kevin_Kofler: well, when we say 1gb image, that's just the name/label we give to the one that's > livecd size
16:00:09 <rdieter> maybe using livedvd label would be safer
16:00:15 <Kevin_Kofler> Last I checked 1 GiB was not a useful target to hit, but that might be different now (CD + Digikam + kipi-plugins + Marble = ?).
16:00:42 <rdieter> Kevin_Kofler: true, 1gb size target itself is arbitrary (and not useful)
16:00:47 <Kevin_Kofler> I found out that depending on what I pick, we're either significantly below or significantly above 1 GiB.
16:01:08 <Kevin_Kofler> CD + kde-l10n-* most definitely doesn't fit in 1 GiB.
16:01:22 <rdieter> 1.5gb would probably be a better target
16:01:46 <Kevin_Kofler> CD + some apps was either significantly below or above 1 GiB depending on "some apps".
16:01:51 <rdieter> Kevin_Kofler: maybe just some selected locales then (but choosing which ones may be hard)
16:02:02 <Kevin_Kofler> I couldn't find a set which makes sense for exactly 1 GiB.
16:02:27 <Kevin_Kofler> If we ship arbitrary selected locales, we'll have people coming up with pitchforks "Why is MY language not included?"
16:02:31 <Kevin_Kofler> Better to not include any. ^^
16:02:59 <rdieter> there's some *obvious* ones, German, French, Spanish, Czech
16:03:22 * Kevin_Kofler picks up pitchfork: What, no Italian??? ^^
16:03:47 <rdieter> Right, choosing the top 6-8 I'd argue wouldn't be too hard.
16:04:10 <Kevin_Kofler> I think we'll soon be in a war over languages.
16:04:34 <rdieter> (maybe even by using some objective criteria like requiring 100% translation coverage, but not sure if that'd omit enough)
16:04:55 <Kevin_Kofler> Large languages will include pt_BR and probably not pt_PT and then we'll have people from Portugal accusing us of breaking Portuguese (remember that flamewar on Planet Fedora?).
16:04:57 <rdieter> Kevin_Kofler: really, you'd rather have *none* than some?
16:05:21 <rdieter> sigh, point the flames at me then, I don't mind
16:05:25 <Kevin_Kofler> (Some guy from Portugal actually left Fedora because of some wiki bug which accidentally showed him a Brazilian translation by default, LOL.)
16:05:39 <Kevin_Kofler> (He said English is better than "wrong Portuguese".)
16:05:40 <nucleo> and by tthe way CD and DVD have the same name now
16:05:42 <rdieter> that's the way it goes
16:06:00 <rdieter> someone with such an attitude, frankly, i'm not sure we were better off *with* them.
16:06:25 <nucleo> I mean CD and DVD iso files should be named differently
16:06:30 <rdieter> nucleo: that should be fixed, agreed.
16:06:49 <Kevin_Kofler> Right now the DVD includes ALL kde-l10n-*.
16:06:51 <rdieter> I thought we'd gotten that fixed?  guess not.
16:07:19 <rdieter> well we're over time, let's conclude the meeting.
16:07:23 <Kevin_Kofler> It ends up somewhere around 1.5 GiB, I'll be able to check the exact size when Calligra will go stable so the broken deps are finally sorted out.
16:07:31 <rdieter> I'd like to pursue offering a > livecd image though
16:07:54 <rdieter> let's continue in #fedora-kde
16:07:57 <rdieter> thanks everyone!
16:08:02 <rdieter> #endmeeting