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