[18:36] <kees> mdeslaur, sbeattie: starting!
[18:36] <mdeslaur> yes!
[18:36] <nxvl> \o/
[18:36] <kees> nxvl: hola!
[18:37] <sbeattie> o/
[18:37] <nxvl> hola!
[18:37] <kees> okay, so, this week, I'm going to try to flush my rally TODO list, and prepare for blackhat/defcon
[18:37] <kees> I'm on community
[18:38] <kees> that's about it from me.  mdeslaur, you're up.
[18:38] <mdeslaur> I just published thunderbird, and will spend rest of day preparing laptop for blackhat
[18:39] <mdeslaur> that's about it
[18:39] <mdeslaur> next!
[18:39] <sbeattie> mdeslaur: it doestakea while for the cement you encase it in to cure.
[18:39] <mdeslaur> sbeattie: yeah :) let's just say it's a "clean" laptop :)
[18:40] <sbeattie> I hope to work through one or more USN publications this week, since I didn't finish it at the sprally.
[18:40] <nxvl> mdeslaur: oh, i got a spare HD
[18:40] <nxvl> mdeslaur: before DF i just swap disks
[18:40] <kees> sprally.  *snicker*
[18:41] <nxvl> it easier
[18:41] <sbeattie> Also, since I did an appalling job of community effort last week, I'll take over triage while jdstrand is on vacation (and possibly blackhat)
[18:41] <kees> sbeattie: ah yeah, how is w3m coming?
[18:41] <kees> sbeattie: every time I tried to do CVE triage last week, mdeslaur had already done it.  :)
[18:41] <sbeattie> kees: my schroots are missing debuild for some reason.
[18:42] <mdeslaur> kees: stop complaining :)
[18:42] <nxvl> btw, jamie told me he was going to publish FF 3.6.8 this week before BH IIRC
[18:42]  * jdstrand is here, but may drop
[18:42] <sbeattie> so I'll dig back into it and see why they weren't installed.
[18:42] <sbeattie> that's about it for me.
[18:42] <sbeattie> have fun at blackhat!
[18:42] <mdeslaur> sbeattie: I don't have debuild in my schroots
[18:43] <mdeslaur> oh, nm...yes, they do
[18:43] <kees> mdeslaur: usually you do the "sbuild" from outside.
[18:43] <kees> er
[18:43] <kees> sbeattie: ^^
[18:43] <kees> mdeslaur: I wasn't complaining.  :)
[18:43] <kees> sbeattie: was umt not working after an "mk-sbuild"?
[18:43] <sbeattie> kees: um, dunno, then, umt build ad build-orig were failing complaining about it.
[18:44] <sbeattie> s/ad/and/
[18:44] <kees> sbeattie: hunh.  well, we can certain help debug.  :)  just let us know where we can help.
[18:44] <sbeattie> kees: sure thing.
[18:44] <jdstrand> shall I go while my connection is still here?
[18:45]  * sbeattie is also still recovering a little from my laptop drive swap.
[18:45] <sbeattie> jdstrand: all yours.
[18:45] <jdstrand> cool
[18:45] <jdstrand> first off, sorry for being late
[18:45] <jdstrand> this week I am at blackhat
[18:45] <jdstrand> and on triage
[18:46] <jdstrand> I'm technically on holiday today and tomorrow, but did manage to publish the firefox update today
[18:46] <kees> heh.
[18:46]  * kees hugs jdstrand
[18:46] <jdstrand> other than that, that's it
[18:46]  * jdstrand hugs kees back :)
[18:47] <sbeattie> jdstrand: as I said, I'll cover triage for you.
[18:47] <jdstrand> oh, I missed that
[18:47] <jdstrand> sbeattie: rockin' :)
[18:47]  * jdstrand hugs sbeattie :)
[18:47] <sbeattie> jdstrand: enjoy your days off!
[18:48] <jdstrand> \o/
[18:48] <jdstrand> thanks :)
[18:48] <kees> jdstrand: have fun!  :)
[18:48] <kees> okay, any other business for the security team?
[19:59] <Riddell> ** Kubuntu Meeting in a minute in #ubuntu-meeting
[19:59] <ScottK> o/
[19:59] <shadeslayer> \o
[20:00] <apachelogger> hullos
[20:00] <padams> hey hey
[20:00]  * apachelogger swiftly needs to swap his system fonts
[20:00] <shadeslayer> heheh
[20:01] <Riddell> neversfelde, apachelogger, rgreening, ScottK: council ping
[20:01] <ScottK> o/
[20:01] <apachelogger> council pong
[20:01] <Riddell> good evening friends
[20:01] <Riddell> https://wiki.kubuntu.org/Kubuntu/Meetings
[20:01] <Quintasan> \o/
[20:01] <Riddell> anyone here for membership?
[20:02] <rgreening> hey
[20:02]  * Quintasan want kubuntu-dev, but after Neon is working
[20:02] <j-b> are there rules somewhere for those kinds of meeting?
[20:02] <Riddell> kubuntu-dev needs talking to kubuntu-dev people, not so much a general meeting
[20:02] <shadeslayer> we need to get bzr-svn working before that ( for kdelibs )
[20:03] <shadeslayer> Quintasan: oh oh btw search for bzr-fastimport
[20:03] <shadeslayer> that might help us
[20:03] <txwikinger> 0/
[20:03] <apachelogger> Quintasan: just get in touch with someone from kubuntu-dev when you are ready
[20:03] <Riddell> j-b: we chat on the topics on the agenda and hopefully come to a conclusion (we can get the council to vote in cases of geniune split opinions)
[20:03] <cwickert> Riddell: I guess I am, but I haven't completed all the necessary steps yet
[20:03] <Riddell> cwickert: let us know if you manage that before the end of the meeting then :)
[20:03] <Riddell> first item is KDE PIM
[20:03] <padams> w00t
[20:04] <shadeslayer> my precious...
[20:04] <Riddell> at Akademy the PIM developers had mixed responses when I asked
[20:04] <ScottK> Riddell: I think it's clear we should stay with 4.4 for Maverick.
[20:04] <Riddell> about whether we should ship 4.4 or 4.5
[20:04] <Riddell> by the end of the week it become clearer that 4.4 would be the sensible thing to do
[20:04] <padams> cwickert: tell them about fedora 14 :)
[20:04] <Riddell> what's happening in fedora 14?
[20:05] <cwickert> Fedora will probably ship 4.4 too
[20:05] <apachelogger> are they merging with suse? :O
[20:05] <Riddell> the argument against 4.4 is that it's unmaintained
[20:05] <cwickert> which is a strong argument IMHO
[20:05] <Riddell> but if it works that's not a problem, and I think the delayed startup for akonadi problems we had in 4.4.2 have gone as far as I can tell
[20:05] <shadeslayer> Riddell: btw im trying out the beta 1 packages, but they work fine for me, i wont say anything else....
[20:05] <ScottK> Riddell: We're stuck with maintaining it for Lucid for 3 years, so having it in Maverick doesn't make it worse.
[20:06] <rgreening> KDE PIM + Kmail2 + Akonadi == FAIL for me
[20:06] <apachelogger> ScottK is absolutely right
[20:06] <Riddell> I've already updated the kde-l10n packages to use translations from PIM 4.4
[20:06] <shadeslayer> maybe beta 2 will bring joy to the world?
[20:06] <Riddell> apachelogger: is he ever wrong?
[20:06] <apachelogger> didn't say that ^^
[20:06] <ScottK> shadeslayer: It can do it for Maverick +1 then.
[20:07] <jtechidna> sorry, power outage
[20:07] <Riddell> now I suspect there are issues in our kdepim packages that should be fixed anyway
[20:07] <ScottK> I think it would be great if someone provides PPA packages for testing, but there's no indication it is or will be ready for production use.
[20:07] <shadeslayer> ScottK: but if we release kde 4.5.1 with maverick, why not new kdepim ?
[20:07] <Riddell> kleopatra and use of gnupg are things I'd like to have reviewed
[20:07] <ScottK> shadeslayer: Because it's not ready.
[20:07] <shadeslayer> ScottK: packages are already in kubuntu experimental ppa
[20:08] <Quintasan> ScottK++
[20:08] <cwickert> ScottK: how do you define "ready"?
[20:08] <Quintasan> shadeslayer: we should make sure that anyone interested will know where they are
[20:08] <apachelogger> us not being the first to loose their head over it
[20:08] <ScottK> cwickert: Usable, stable, won't eat my data.
[20:09] <apachelogger> we had KDE 4.0 and got a beating, even though it was not even default
[20:09] <shadeslayer> Quintasan: the site would be a BAD idea :P
[20:09] <Riddell> able to safely upgrade from previous versions is an important requirement for "ready"
[20:09] <ScottK> PIM is the one area where data loss hurts users the most and we should be conservative about it.
[20:09] <apachelogger> then we had KDEPim 4.4 as one of the first and got a beating for kaddressbook and akonadi
[20:09] <apachelogger> ...
[20:09] <apachelogger> :/
[20:09] <ScottK> Riddell: Yes.  That too.
[20:09] <shadeslayer> Riddell: afaik no one had failures on lucid and i tested them out on maverick
[20:09] <Quintasan> well, fresh install here, works just fine
[20:09] <cwickert> ScottK: AFAIK it's not eating data anymore. we are running a many test systems with real life data
[20:09] <JontheEchidna> upstream is not defining it as "ready" as it is: http://simplest-image-hosting.net/jpg-0-plasma-desktophx9879
[20:09] <Riddell> shadeslayer: rgreening just said he had fail
[20:10] <shadeslayer> rgreening: did the upgrades fail, or the app itself?
[20:10] <ScottK> cwickert: I think when it can meet the normal KDE release schedule that'll be a sign it's mature enough to consider.
[20:10] <rgreening> For me, on lucid that is, Kmail2 and Akonadi == 100% CPU and I cannot delete mail from my GMAIL IMAP.
[20:11] <rgreening> it takes forever to load the message and cant delete. it's unusable
[20:11] <JontheEchidna> for me, kmail2 + akonadi == akonadi-mysql taking up 100 MiB of memory while idle
[20:11] <ScottK> If it's too scary for Fedora, I'm reasonaly certain it's too scary for us.
[20:11] <apachelogger> ^^
[20:12] <JontheEchidna> So it looks like pieces are already set in place for keeping 4.4 for maverick. l10n is taken care of and 4.5 is in the experimental PPA. I think we should motion to keep it this way
[20:12] <apachelogger> also, if a release would happen I suppose itwould be jolly close to our own release
[20:12] <ScottK> With 4.4, Kmail is usable on my netbook with 1GB RAM and an Atom CPU.  It doesn't sound like that would work at all well with Kmail2.
[20:12] <Riddell> apachelogger: yes, since we're releasing at the start of october not the end
[20:12] <apachelogger> and history tells that this is never a good thing
[20:12] <cwickert> ScottK: the decision for Fedora is not set in stone yet
[20:13] <cwickert> ScottK: but Fedora has one month more until they release then Kubuntu
[20:13] <apachelogger> I think we agree that KDEPim 4.5 is no option for 10.10
[20:13] <cwickert> s/then/than
[20:13] <Quintasan> apachelogger++
[20:13] <apachelogger> should be revisited at next UDS if possible though
[20:13] <ScottK> apachelogger: I think so.
[20:13] <apachelogger> to lay out a migration plan
[20:13] <ScottK> I think we should definitely plan on it for 11.04 though.
[20:14]  * padams agrees
[20:14] <shadeslayer> apachelogger: +1
[20:14] <apachelogger> aye
[20:14] <rgreening> I agree. it's way too critical to foo someones mail
[20:14] <Riddell> padams, cwickert: will kolabsys be wanting to review our packages in some way?  and are there KDE PIM 3.5 packages we should care about?
[20:14] <cwickert> Riddell: yes there are packages
[20:14] <Riddell> ..but should we care? :)
[20:15] <ScottK> Riddell: I think we should get the Kolab 3.5 packages in.
[20:15] <cwickert> Riddell: I think you should. I ready suggested to have the e3.5 client as an alternative a while back
[20:15] <padams> that's up to you… we can help provide 3.5 packages and we can help with the 4,5 effort because we would like to see 4,5 packages for lucid
[20:15] <Quintasan> If someone cares for 4.5 we have packages, right? So we can just tell them it can eat data but if users want to test it then go ahead
[20:16] <ScottK> padams: I think it we are interested in providing 4.5 packages for people that want them via PPA, just not in the main repository.
[20:17] <apachelogger> ack
[20:17] <ScottK> It would be good both for testing and for early adopters.
[20:17] <padams> ScottK: fine with me
[20:17] <cwickert> ScottK: how about 3.5 then?
[20:17] <Quintasan> shadeslayer: you were the one doing 4.5beta1 packages?
[20:17] <cwickert> should this be in the main repo or also in a ppa?
[20:17] <ScottK> I think 3.5 in Lucid is fine.
[20:17] <shadeslayer> Quintasan: yep
[20:17] <shadeslayer> theyre in experimental ppa
[20:17] <Quintasan> great
[20:18] <ScottK> cwickert: We just need to make sure they are correctly "branded" as Kolab kdepim so people don't get confused.
[20:18] <padams> ScottK: or kdepim-ultra-old?
[20:18] <cwickert> ScottK: so how would you do that?
[20:18] <cwickert> kdepim-rock-stable
[20:19] <ScottK> In the package name and description.
[20:19] <ScottK> It should be easy enough, we just need to remember to do it.
[20:19] <Riddell> ScottK: in Lucid?  as in backports?
[20:20] <ScottK> Riddell: Maverick and then Lucid Backports, yes.
[20:20] <ScottK> Riddell: I think the key is to position them as part of the Kolab system, not part of the KDE system.  Then users won't be confused.
[20:20] <Riddell> padams, cwickert: how can we get 3.5 packaging moving?
[20:21] <cwickert> Riddell: good question, I'm open to suggestions cause I don't know the (k)ubuntu workflow
[20:22] <ScottK> Riddell: I think for the purposes of the meeting, we can agree we want them and I'll chat with cwickert later and sort out the details.
[20:22] <Riddell> cwickert: I'd suggest turning up on #kubuntu-devel and asking for people to review the packaging you have
[20:22] <cwickert> Riddell: ok
[20:22]  * Quintasan wants to try that
[20:22] <ScottK> I think we've agreed on the following for Maverick and KDEpim: KDE 4.4 for Maverick, Kmail2/4.5 in PPA, and KDE3.5 PIM packages for Kolab.
[20:23] <ScottK> Any objections to that?
[20:23] <apachelogger> cwickert: you make a package, show it to us, we will tell you that it is crap, you come with a new package, we will love it and then one who has appropriate permissions will upload ;)
[20:23] <apachelogger> something like that in any case ;)
[20:23] <JontheEchidna> ScottK: none here
[20:23] <apachelogger> no objections
[20:23] <Riddell> ack on that
[20:24] <Riddell> as I said before we should look at the gnupg and kleopatra packaging for 4.4
[20:24] <cwickert> apachelogger: sounds good, but can we please skip the first step? ;)
[20:24] <Riddell> padams, cwickert: at the distro sprint last week the server team people suggested you turn up at a server team meeting sometime soon to look at the kolab server bits
[20:24] <apachelogger> cwickert: awww, less fun for us :P ... but I suppose we can live without it ;)
[20:24] <Riddell> their meetings happen on Tuesdays, not sure the time
[20:25] <ScottK> I'll help them out with that.
[20:25] <cwickert> apachelogger: you could have a look at http://files.kolab.org/apt/ubuntu/dists/karmic/kdepim-e35-extras/source/
[20:25] <Riddell> August 12th
[20:25] <Riddell> FeatureFreeze
[20:25] <Riddell> that's the date to remember :)
[20:25] <Riddell> groovy, moving on?
[20:25] <apachelogger> uhh, the return of arts ^^
[20:25] <cwickert> Riddell: please drop us a note when you are going to talk about kolab
[20:26] <ScottK> cwickert: Will do.  I'd like to get the cyrus patches in first.
[20:26] <shadeslayer> btw a patch in kdepim beta 1 needs fixing
[20:27] <shadeslayer> if anyone is up for it :D
[20:27] <ScottK> cwickert: We've totally removed arts from the distro.  It would be super helpful if we could work around needing it again.
[20:27]  * apachelogger assigns the task to shadeslayer
[20:27] <padams> ScottK: patches coming your way soon
[20:27] <shadeslayer> apachelogger: heh :P
[20:27] <ScottK> Excellent.
[20:27] <apachelogger> oh, no arts :(
[20:27] <shadeslayer> apachelogger: i fail at refreshing patches
[20:27] <cwickert> ScottK: yeah, lets try to avoid arts...
[20:27] <apachelogger> shadeslayer: something to learn then
[20:27] <apachelogger> so
[20:27] <apachelogger> shall we move on?
[20:27] <Riddell> Video Player?
[20:27]  * apachelogger pokes j-b
[20:28]  * j-b pokes back
[20:28] <Riddell> Kaffeine doesn't seem ready
[20:28] <ScottK> Agreed.
[20:28] <Quintasan> +1
[20:28] <Riddell> personally I'd like to avoid adding another media framework
[20:28] <Riddell> and I'd like to have a nice KDE UI
[20:28] <Riddell> which leads back to Dragon
[20:28] <Quintasan> I would vote in favour in SMPlayer but that seems impossible due to CD space and licensing reasons, I'm I right?
[20:28] <apachelogger> Quintasan: also it looks like ewww :P
[20:28] <apachelogger> so
[20:29] <apachelogger> I propose vlc
[20:29] <apachelogger> because
[20:29] <JontheEchidna> Quintasan: licensing has made any mplayer-based solution impossible
[20:29] <shadeslayer> vlc+1
[20:29] <apachelogger> the nice people at amarok are pushing phonon-vlc and call it the next-gen phonon backend
[20:29] <shadeslayer> also like i pointed out earlier, anyone migrating from windows will have a easy time with it
[20:29] <Riddell> SMPlayer has a semi-KDEish UI but it's not great and not dl loading avcodecs means it's out
[20:29] <apachelogger> so, if they are right we will end up with libvlc in the long run
[20:29] <Quintasan> apachelogger: SMPlayer look eww? If you didn't even bother to look at the options then :3
[20:29] <ScottK> What's compelling enough about VLC to make it worth switching now and maybe switching to Kaffeine in 11.04?
[20:30] <apachelogger> I am quite sure j-b can reason why vlc would be a good choice
[20:30] <Riddell> phonon-vlc didn't work too well when I tried it, although I see a new release has just been made
[20:30] <shadeslayer> ScottK: id rather bangarang than kaffeine
[20:30] <j-b> well, vlc might be a good choice, because it is plugin-based, as GStreamer, which makes it easier to distribute in parts
[20:30] <ScottK> shadeslayer: Kaffeine/some other choice
[20:31] <j-b> but I guess CD size is annoying for you.
[20:31] <Riddell> vlc's player UI is not pretty at all in my opinion
[20:31]  * apachelogger agrees with Riddell
[20:31] <apachelogger> OTOH millions of windows users use it
[20:31] <Riddell> it also needs some packaging and MIR love to get vlc into main and it's getting a bit late in the cycle for that
[20:31] <apachelogger> so vlc could very well be a selling reason
[20:32] <Quintasan> j-b: I have one question about the VLC, Are the problems with mkv files crashing VLC solved?
[20:32] <j-b> Quintasan: yes.
[20:32] <j-b> Quintasan: crashing wasn't a vlc problem but a libebml one, that is fixed in libebml 1.0.x
[20:32] <apachelogger> Riddell: how about dragon for 10.10 and vlc as prospective target for 11.04?
[20:32] <Riddell> the advantages of Kaffeine are DVB support and subtitles, j-b how does vlc manage with those?
[20:32] <apachelogger> supposedly phonon-vlc is also more mature by then
[20:33] <j-b> Sorry to be rude guys, but what is so difficult in actually coding a correct phonon player?
[20:33] <shadeslayer> also phonon-vlc currently crashes for me on maverick
[20:33] <j-b> shadeslayer: stacktraces are welcome.
[20:33] <shadeslayer> so whenever i quit a app, i get that foobar app has crashed
[20:33] <shadeslayer> j-b: on bugs.kde.org ?
[20:33] <Riddell> j-b: dragon is a correct phonon player, for some reason kaffeine isn't using phonon which is what leads it to have problems
[20:33] <apachelogger> j-b: it is more the maintaining than the coding IMHO
[20:34] <apachelogger> dragon was also maintainerless for quite some time
[20:34] <j-b> shadeslayer: I believe I fixed that bug in latest release, but yes, bugs.kde.org
[20:34] <Quintasan> Riddell: I do not think subtitles are a problem, I have many Matroska files (with SSA subs inside), and VLC had problems with them, but now it is all fixed
[20:34] <Quintasan> Problems == crashing
[20:34] <shadeslayer> j-b: ok which is the latest release again ? :D
[20:34] <j-b> shadeslayer: we have 2 students working on improving phonon and phonon-vlc
[20:34] <Riddell> j-b: does vlc talk to pulseaudio properly?
[20:34] <j-b> shadeslayer: 0.2.0
[20:34] <txwikinger> why are we planning to change every release?
[20:34] <j-b> Riddell: properly, as in "as well as gstreamer", no. But better than mplayer, yes.
[20:34] <shadeslayer> seems that needs packaging
[20:35] <Quintasan> txwikinger: because it seems that Dragon Player was ultimate failure?
[20:35] <j-b> 21:33 < apachelogger> j-b: it is more the maintaining than the coding IMHO
[20:35] <j-b> apachelogger: come on...
[20:35] <Quintasan> at least that's what I heard
[20:35] <Riddell> Dragon Player is fine, nothing failure about it, just a bit limited
[20:35]  * txwikinger thinks it is very confusing for users if the packages change every release
[20:35] <j-b> Riddell: DVB, yes. Subs, of course
[20:35]  * apachelogger agrees with txwikinger
[20:35]  * ryanakca agress with txwikinger too
[20:36] <Riddell> j-b: I don't suppose there are any plans to make the vlc UI pretty and using oxygen icons?
[20:36] <j-b> Riddell: ask what you need, and you will get it.
[20:36] <j-b> Riddell: it is as simple as that.
[20:36] <Riddell> now there's service :)
[20:36] <j-b> oxygen icons, is like 20 LoC
[20:36] <apachelogger> mhhh, that is servie a la quassel
[20:36]  * apachelogger lieks that :D
[20:37] <j-b> Riddell: seriously, I don't care if VLC gets inside Kubuntu, or not, that is not my choice and I am biaised. But if you need things, just ask.
[20:37] <j-b> and my opinion, as a KDE user is that you need a proper phonon player
[20:38] <Riddell> j-b: which would count out the vlc UI?
[20:38] <j-b> Riddell: I don't understand the question, sorry.
[20:39] <Riddell> j-b: vlc's UI isn't a phonon player
[20:39] <j-b> and won't.
[20:39] <Riddell> dragon is the only one I know of
[20:39] <apachelogger> there are a couple of others on qt-apps IIRC
[20:39] <j-b> Riddell: Kaffeine? banganrang?
[20:39] <apachelogger> nothing terribly awesome though
[20:39] <ScottK> It sounds to me like we ought to stay with Dragon for now and take another look for Maverick +1.
[20:39] <apachelogger> oh yeah, bangarang is also there :D
[20:39] <Riddell> Kaffeine is hard coded to xine
[20:40] <apachelogger> j-b: kaffeine uses xine directly
[20:40] <Riddell> isn't banganrang music focused?
[20:40] <j-b> WHHHHHHHHHAT?
[20:40] <j-b> OMG, not xine...
[20:40] <apachelogger> Riddell: no, collection focused if anything
[20:40] <shadeslayer> rgreening: no.. its good for video as well
[20:40] <shadeslayer> brr
[20:40]  * apachelogger hands j-b a cookie to calm him down ^^
[20:40] <shadeslayer> Riddell: ^^
[20:40] <Riddell> "Beside all the nice improvements Kaffeine is (again) directly using xine-lib instead of Phonon. " http://kaffeine.kde.org/
[20:40] <apachelogger> Well.
[20:41] <Riddell> which is why it doesn't work with my USB headphones
[20:41] <apachelogger> Since I agree with txwikinger who is not amused about changing apps over and over again.
[20:41] <apachelogger> I say we stay with dragon for 10.10
[20:41] <Riddell> yes
[20:41] <apachelogger> and look at this issue proper
[20:41] <kstar> Sorry to butt into a meeting with an offtopic message, but just wanted to thank all of you for making such a rocking distribution.
[20:41] <apachelogger> to either improve dragon towards become awsomest
[20:41] <shadeslayer> well.. i think vlc for maverick+1
[20:41] <apachelogger> or consider vlc for 11.04
[20:41] <Adityab> vlc++
[20:42] <j-b> apachelogger: recoding an actual phonon player isn't difficult, IMVHO
[20:42] <ScottK> Any objections to Dragon for Maverick and consider it again at UDS for Maverick +1.
[20:42] <Riddell> I think that's agreed
[20:42] <ScottK> Shall we move on then?
[20:42] <apachelogger> aye
[20:42] <Riddell> message indicator is the next topic
[20:42] <kstar> VLC is a good thing because Windows folk use VLC.
[20:43] <apachelogger> j-b: the only time I ever looked at phonon was to play a video for a hoax application :)
[20:43] <j-b> Mac people the same :)
[20:43] <apachelogger> maybe I should look at it again
[20:43] <apachelogger> j-b: well, thanks for attending :)
[20:43] <j-b> apachelogger: no pb
[20:43] <j-b> please, guys, if you need modifications to VLC or phonon-vlc, just _ask_
[20:43] <j-b> seriously
[20:44] <maco> i thought mac & windows people used whatever was default in their OSes...which definitely isnt vlc
[20:44] <highvoltage> <3 VLC! (just had to chime in)
[20:44] <ScottK> I think for M-I, the proposal is on by default for Quassel and Kopete, but not Kmail and no systray icons for Quassel or Kopete.
[20:44] <j-b> maco: believe me, linux is the smallest of our OSes
[20:44] <apachelogger> maco: they have tech friends who install VLC along with Firefox
[20:44] <Riddell> message indicator has had some improvements since we last discussed it and I think we should have it used by default in maverick
[20:44] <apachelogger> why is message indiciator not used by upstream?
[20:45] <Riddell> which upstream?
[20:45] <ScottK> apachelogger: All the patches are upstream.
[20:45] <apachelogger> well
[20:45] <Riddell> it is in Quassel and kmail and kopete upstream
[20:45] <apachelogger> active by default
[20:46] <ScottK> Since it's extragear, I don't think it can be active by default for Kmail/Kopete
[20:46] <apachelogger> using message indicator would be a pretty grave change to how that sort of stuff appears in the KDE workspace isnt it?
[20:46] <Riddell> but the plasmoid itself isn't in because aseigo wants it implementing using the status notifier protocol, trouble is nobody knows how you can squash what MI needs into that protocol
[20:47] <Riddell> ScottK: agateau and me discussed some ideas for KMail, it probably needs a whole config dialogue page to itself since how you need it to work depends on how you use your e-mail
[20:47] <ScottK> apachelogger: We've provided the MI widget by default for a few cycles now.  I don't think some enabling would be a grave change.
[20:47] <ScottK> Riddell: Makes sense.  I think that should be Maverick +1.
[20:47] <Riddell> yes
[20:47] <ScottK> No point in doing all that for Kmail right before we switch to Kmail2.
[20:48] <Riddell> also relevant kwwii said he could probably do a new icon for maverick
[20:48] <apachelogger> but enabling it changes how kopete/kmail/quassel notifications are displayed?
[20:48] <Riddell> the current star isn't too noticable (although that could be a feature for some people) and it doesn't quite fit in with the new systray icons theme
[20:49] <Riddell> apachelogger: by not cluttering your systray
[20:49] <Riddell> which is a win for me
[20:50] <apachelogger> well, if upstream likes us to enable it I am all for it
[20:50] <ScottK> apachelogger: It doesn't affect notifications, only systray.
[20:50] <apachelogger> ScottK: so you still get notifications?
[20:50] <ScottK> Yes
[20:50] <Riddell> yes the VisualNotifications wouldn't change
[20:50] <Quintasan> That quite defeats the point of MI IMO
[20:50] <ScottK> Quintasan: You can turn them off if you want.
[20:50] <apachelogger> hm
[20:50] <ScottK> (at least for quassel)
[20:51] <apachelogger> ahhhh, but the tray icons would be gone?
[20:51] <ScottK> Yes
[20:51] <Riddell> yes, pointless tray icons won't be missed by me
[20:51] <ScottK> You could put it back if you wanted.
[20:51] <maco> oh a less cluttered tray? i like that
[20:51] <apachelogger> isnt that what the tray redesign + kstatusnotifier is supposed to archive? :P
[20:52] <apachelogger> well, I think we should go with it and advertise it
[20:52] <Riddell> and make sure upstreams are aware and don't object of course
[20:52] <apachelogger> if people start complaingin soon enough we should revert though
[20:53] <apachelogger> for the sake of not angering the users with every release
[20:53] <ScottK> There's a checkbox to re-enable the systray icon for kopete too.
[20:53] <Riddell> next item?
[20:53] <Riddell> Ubuntu font
[20:53] <ScottK> What's to discuss about it?
[20:54] <Riddell> whether we want it on by default
[20:54] <Riddell> although the Ubuntu Desktop team don't know it yet, they're going to have it included at some point soonish
[20:54] <Adityab> font++
[20:54] <Riddell> I think all kubuntu members have access to try it out
[20:54] <ScottK> Yes.
[20:54] <apachelogger> The font handles umlauts quite terribly
[20:54]  * ScottK thought the Ubuntu font was the font for the Ubuntu logo.
[20:55] <apachelogger> I pointed out some of the immediately visible things earlier in kubuntu-devel
[20:55]  * ScottK didn't realize it was something for the actual system.
[20:55] <Quintasan> and it looks quite awful on my 23" display
[20:55] <Quintasan> too thin
[20:55] <Riddell> ScottK: it's for the whole system font
[20:55] <ScottK> Riddell: Yes.  I've just learned this.
[20:55] <Riddell> it takes a little getting used to but I find it makes my desktop more interesting without being distracting
[20:55] <JontheEchidna> I enjoy the font as well
[20:55] <Riddell> nuno also likes it, not as much as liberation but more so than dejavu
[20:55] <apachelogger> dejavu is utter crap I may say so
[20:56] <ScottK> Do currently match upstream on font or are we already different?
[20:56] <apachelogger> I am also more for liberation
[20:56] <JontheEchidna> apachelogger: they are taking feedback about the font, so I would suggest that you report the umlaut issues as a bug
[20:56] <Riddell> upstream has no font, it's an X issue
[20:56] <shadeslayer> oh font
[20:56] <ScottK> Ah.
[20:56] <shadeslayer> ubuntu font ++
[20:56] <shadeslayer> along with autohinting
[20:56] <apachelogger> also liberation is more established and since the font is only supposed to go into public beta on 8th august or so...
[20:56] <ScottK> It sounds to me like it's premature to make a decision.
[20:57] <apachelogger> ScottK: upstream == nuno == liberation | droid
[20:57] <txwikinger> isn't it quite simple to change the default font anyway?
[20:57] <apachelogger> with which I agreee entirely
[20:57] <Quintasan> apachelogger: +1
[20:57] <Riddell> I think it would be a nice bit of cross-Ubuntu-variant cohesiveness to use it
[20:57] <ScottK> Riddell: I'd propose we revist after it's public.
[20:57]  * apachelogger would postpone to UDS actually
[20:58] <apachelogger> discuss this at larger scale
[20:58] <Quintasan> Does anyone know how the asian symbols look in Dejavu fonts?
[20:58] <JontheEchidna> UDS is after release though
[20:58] <JontheEchidna> way too late
[20:58] <Riddell> it is public now, you can share it as you want so long as it's obvious it's a beta, it just isn't freely licenced yet
[20:58] <ScottK> or not
[20:58] <ScottK> Riddell: I guess that's the other thing, I'm not comfortable with deciding for it until the license terms are finalized.
[20:59] <apachelogger> I am highly against changing the default font this late....
[20:59] <apachelogger> and until it is public it is getting even later...
[20:59] <Quintasan> One question, did anyone actually complain about the font being bad?
[20:59] <Riddell> ScottK: as a free software zealot I'm not going to touch it if the licence turns out not to be free, but I don't think that'll happen
[20:59] <JontheEchidna> this late? we're not even at the third alpha, and we were considering changing font at RC last cycle
[20:59] <apachelogger> und then it will be too late when suddently it turns out that something is horribly broken...
[20:59] <ScottK> Riddell: I don't think it will happen either, but I think we should accept it after, not before.
[21:00]  * Mamarok doesn't liek the Ubuntu font
[21:00] <ScottK> Considering it's easy to switch defaults, I'm not overly concerned about deciding this up to beta.
[21:00] <Mamarok> like*
[21:00] <apachelogger> JontheEchidna: that font was not beta though
[21:00] <apachelogger> in fact that font was around for years
[21:00] <JontheEchidna> and it won't be once its released
[21:01] <JontheEchidna> and defaults are easy enough to change if there is a problem, as Scott noted
[21:01] <Riddell> ScottK: it's mostly a problem for docs, not sure when they would want a decision by
[21:01] <Riddell> a new version with bold is expected this week
[21:02] <Riddell> let's check with our docs people when they need a decision and make sure we do decide before then
[21:03] <ScottK> User interface freeze and beta freeze are the same day
[21:03] <ScottK> So I think it's fine to wait.
[21:03] <apachelogger> would we be using it for anything but menus?
[21:04] <apachelogger> like actual text? (say browser)
[21:04] <Riddell> apachelogger: fiddly to only make it apply to menus, I'd expect everything but fixed width fonts
[21:04] <Riddell> (because that won't be done in time as I understand it)
[21:05] <Riddell> I also had "rekonq defaults" on the agenda, although it seems less important given we don't know if rekonq will be supported for Qt 4.7/KDE Platform 4.5
[21:05]  * apachelogger says -1 then because he finds the font very horrible for floating text - besides currently being essentially broken with umlauts
[21:05] <Riddell> I need to contact the rekonq developers and get an answer on that
[21:06] <shadeslayer> Riddell: a poke on rekonq@kde.org? :)
[21:06] <Riddell> the agenda item was about removing all bookmarks from rekonq by default, settings homepage to google.com and setting default webpages to
[21:06] <Riddell> +        <default>http://www.google.com,http://userbase.kde.org,http://www.kubuntu.org,http://www.kubuntuforums.net</default>
[21:07] <Riddell> it's not ideal to hard code in google.com, would be better to use searchproviders somehow but I don't think that's possible
[21:08] <ScottK> Riddell: I think it's pretty clear rekonq is unsuitable for default.
[21:08] <apachelogger> ack
[21:08] <ScottK> I'd thought we were going to discuss switching away from it.
[21:08]  * Quintasan votes in favour of Konq and option of installing kpart-webkit
[21:09] <ScottK> Arora is better, but still crashy on flash stuff.
[21:09] <txwikinger> konq is really lacking a lot of important features
[21:09] <Riddell> ScottK: rekonq 0.5 is far too crashy but 1.0 is due out before maverick and maybe they'll support qt 4.7 with that, needs asking anyway
[21:09] <ScottK> Riddell: When is it due?
[21:10] <apachelogger> I would like to bring up trying konq + kwebkitpart for one release since it performs a lot better in the reliability
[21:10] <ScottK> We're running out of time "before Maverick".
[21:10] <Riddell> ScottK: they have said they can do it to our schedule
[21:10] <txwikinger> Is konq actively developed?
[21:10] <Riddell> txwikinger: yes, khtml has improved in 4.5 to some extent
[21:10] <ScottK> Riddell: The fact that I can't currently file a bug that won't get marked invalid immediately I find highly discouraging.
[21:10] <txwikinger> Riddell: and the GUI?
[21:10] <shadeslayer> txwikinger: yep, i was told to ditch development on rekonq and work on konqueror on #kde-devel one day :P
[21:11] <apachelogger> kthml just doesnt have nokia and apple and google in its back :)
[21:11]  * txwikinger wants tabs that can be re-ordered
[21:12] <ScottK> Riddell: I think we should switch back to Konqueror now and consider Rekonq when there is something that might be suitable.
[21:12] <apachelogger> well, I am for trying konq+kwebkitpart but really think we should be using firefox to begin with and other than that does not care
[21:12] <Riddell> ScottK: I'm happy with that
[21:12] <ScottK> Konqueror + khtml is a better choice than Rekonq right now.
[21:12] <ScottK> apachelogger: We'd need to figure out how to deal with options that don't work with webkit if we shipped that.
[21:13]  * txwikinger is for kwebkit whatever browser it will be
[21:13] <ScottK> txwikinger: The problem is that we don't have any that are at all end user suitable at the moment.
[21:13] <apachelogger> ScottK: I do not think they are that many
[21:13] <apachelogger> oh oh oh, someone please make sure that with whatever browser we use that java works
[21:13] <ScottK> apachelogger: OK.  We'd need to figure that out before switching to it.
[21:14] <maco> txwikinger: mmm wait isnt webkit not-screenreader-friendly?
[21:14] <apachelogger> ScottK: I am suggesting to try it for a pre-release and see how it goes
[21:14] <apachelogger> so that we do not look into hiding stuff that doesnt need to be hidden because we do not ship with the webkitpart anyway
[21:15] <maco> txwikinger: nevermind, that doesnt matter on kubuntu. nothing qt is screenreader friendly to start with
[21:15]  * txwikinger needs webkit for the debugging stuff
[21:16] <Riddell> if someone wants to review konq+webkitkde and work out how stable it is and what breaks in the config UI that would be great
[21:16] <ScottK> txwikinger: Yes, but you can install stuff.  That's not a reason to make it default.
[21:17] <txwikinger> ScottK: Sure I can install firefox :p
[21:17] <ScottK> txwikinger: That won't get you webkit.
[21:17] <ScottK> ;-)
[21:17] <txwikinger> but firebug
[21:18] <Riddell> any other business?
[21:18] <ScottK> Any objections to Konqueor +khtml for now and Konqueror + webkit or Rekonq once we have a solid proposal and something that is tested to work reliably?
[21:18] <ScottK> Riddell: Is ^^^^ what you think we decided?
[21:18] <Riddell> ScottK: yes
[21:18] <ScottK> Excellent.
[21:18] <apachelogger> ScottK: looks like the settings are written all and entirely in cpp
[21:19] <apachelogger> given a list of features that do not work with the webkitpart one can easily disable that stuff
[21:19] <ScottK> apachelogger: All we need is someone to research it, provide a patch, and test.
[21:20] <apachelogger> I think research is the biggest problem there ^^
[21:20] <ScottK> shadeslayer is a rekonq fanboi, so we need another minion for that.
[21:20] <shadeslayer> \o/
[21:20] <shadeslayer> if someone kares enough to train me :P
[21:21]  * txwikinger tests out konq+webkit
[21:21] <ScottK> Riddell: I suspect we can close the meeting.
[21:21] <Riddell> yes, 4.5 final tagging due tomorrow or next day
[21:21]  * apachelogger hands everyone a cookie
[21:21] <Riddell> so ninjas and testers needed after that
[21:21] <shadeslayer> ahem... 4.5 rc was tagged
[21:21] <Riddell> thanks all
[21:21] <shadeslayer> \o
[21:21] <j-b> Now that your meeting is over, can anyone explain me why Kaffeine doesn't use phonon anymore?
[21:22] <Riddell> j-b: let's move to #kubuntu-devel
[21:22] <j-b> ok