[00:27] starcraftman: needs to be changed I suppose :D [00:27] ScottK, Riddell: why is spec review not on the meeting agenda? [00:27] or is it hiding behind the todo list review? [00:27] apachelogger: Because you didn't write it there? [00:28] * apachelogger is not much of a writer [00:28] apachelogger: aye, this weekend when I get some free time will see what can be done. Also gotta do that coop report too. [00:30] ScottK: oh well, since we only have one proper spec... [00:31] apachelogger: Need to decide about translations based on the information gathered at UDS and then add appropriate items to the TODO. [00:31] There is a spec for this. [00:31] https://blueprints.launchpad.net/ubuntu/+spec/packageselection-kubuntu-n-translations [00:33] not linked on the UDSNatty page [00:34] or sleepy eye syndrom is taking over again [00:36] Would you please fix it. === jjesse_ is now known as jjesse === muesli_ is now known as muesli [07:33] gmorning all === hrw|gone is now known as hrw [09:23] ulysses: can you try installing krdc and see if it works with 4.5.3 and Qt 4.7? [09:24] Riddell: can i start moving stuff from Staging to backports [10:16] shadeslayer: go for it [10:17] okies [10:51] shadeslayer: krdc installed [10:51] ulysses: does it start? [10:52] and im moving stuff to backports PPA :) [10:52] right now LP is going kaboom if i copy 2 packages [10:53] shadeslayer: yes [10:53] great [10:56] someday [10:56] launchpad will work [10:56] someday.... [10:57] shadeslayer: timeouts when copying? [10:57] aye [10:58] with just one package at a time [10:58] amarok won't start either… [10:58] ulysses: wha... [10:58] didnt you get a update? [10:59] this is after update [10:59] so it just doesnt start? [11:00] the console output: http://pastebin.com/MQwBE0NL [11:00] thats it? 0_o [11:01] ulysses: try : amarok -d [11:02] same output [11:02] i think i need amarok-dbg :P [11:02] markey: ^^ [11:03] ive copied all the stuff..... [11:03] Riddell: ^^ [11:04] backports also has KDE PIM 4.4.7 [11:08] shadeslayer: now you need to test it again before announcing [11:09] oh [11:10] shadeslayer: mistakes can be made in the copying [11:10] right [11:10] sec please [11:10] busy [11:10] "amarok --debug --nofork" [11:10] ^ [11:11] http://pastebin.com/x5tWWT0K [11:11] useless... [11:11] install amarok-dgb [11:11] then: "gdb amarok" [11:12] then: "run --nofork" [11:12] ...wait for crash [11:12] then: "thread apply all bt" [11:12] and pastebin it [11:12] s/dgb/dbg [11:14] this was it [11:14] no crash because Amarok doesn't start [11:15] kaboom [11:15] Riddell: any ideas on this ^^ [11:15] oh.. seems amarok tries to send signals but theyre not found [11:16] shadeslayer: on what? [11:17] amarok not starting [11:17] shadeslayer: with 4.5.3 on lucid? [11:17] yes [11:18] dunno, let me test [11:18] sure [11:21] ulysses: till then try installing kubuntu-desktop again [11:22] it does nothing [11:24] * shadeslayer installs kde-full to test [11:36] this will take a hour and half atleast :) [11:40] * Riddell adds kpat and phonon-backend-gstreamer to the CD [11:53] JontheEchidna: what happened to the upload of this? https://launchpad.net/ubuntu/+source/gtk2-engines-oxygen [11:56] lp gobbled it up :> [11:58] Riddell: We really wanted this: http://gitorious.org/oxygen-gtk plus that one doesn't have a proper copying file [12:01] JontheEchidna: what's the difference? [12:01] JontheEchidna: copying file? [12:02] Riddell: oxygen-gtk is made by the guy who coded the Qt theme, and is better than the other one [12:03] and the other one lacks a COPYING.LIB file for the LGPL [12:03] Riddell: thats the one i showed you [12:03] ah [12:03] JontheEchidna: so you plan to package that at some point? [12:03] the one JontheEchidna is mentioning is the one that was running on my system [12:04] Riddell: I'll try to do it later today [12:05] lovely [12:05] firefox crashes with the old style when I open properties so hopefully this one will be better :) === yofel_ is now known as yofel [12:09] :) [12:13] bbl [12:48] Riddell: any news on the amarok thingy? [12:49] shadeslayer: just ran it, works fine [12:49] ulysses: ^_^ [12:49] its just you :P [13:00] shadeslayer: that was testing from backports PPA too so it's good to go as far as I'm concerned [13:00] oooog [13:00] ooh [13:00] well.. i have 5 mins left of kde-full download [13:01] i think we should let that run ^_^ [13:01] yes, do [13:01] never take my word for it, always check yourself too [13:01] and vice versa [13:02] :) [13:13] Riddell: ogra just re-uploaded the no-neon SRU for Qt. Given runtime detection is broken (and apparently non-trivial to fix), I think I have a hard time arguing with this. He did promise to put a neon version in a public PPA somewhere. [13:13] rbelem: ^^^ [13:14] yeah, seems we'll lose on that one [13:14] has the runtime detection issue been reported upstream? [13:15] Thiago's been active on the bug, so he's aware, but I don't know if there's a formal bug report. [13:15] ScottK: do happen to have an SD image for the efika/pegatron you could share? Im struggling to get something that works :/ its frustrating. [13:16] jussi: No. Mine are still running the Karmic kernel they came with. [13:16] ScottK: that would still be better than the jaunty I have... :/ [13:16] jussi: I suspect at least part of your problem is that what you have isn't exactly the same as Efika. [13:17] ScottK: perhaps. [13:17] What I have is the same as what's on their web site. [13:29] Riddell: everything fine at my end :) [13:31] shadeslayer: :( [13:31] ulysses: possibly markey can help [13:31] but no idea why it doesnt start.... [13:32] try removing the amarok config file from .kde/share/config [13:32] thats all i can think of [13:35] I removed ~/.kde/share/apps/amarok too, now it starts [13:36] It works now fine. [13:37] now back to hupnp, I have a lot of things to fix:P [13:40] :P [13:53] Riddell: qmake is kicking my behind. I got the proper CXXFLAG to pass to work around the GCC issue, but it looks to me like QMAKE_CXXFLAGS is getting stomped on during the build as the added flag is there and then goes away. [13:53] Riddell: It happens right about the same time "QMAKE_CXXFLAGS *= -mfpu=neon" gets referenced in src/corelib/corelib.pro [13:54] Does anyone know what the difference between += and *= is? === Riddell changed the topic of #kubuntu-devel to: Kubuntu - Friendly Computing | Lots to do https://wiki.kubuntu.org/Kubuntu/Todo | SRUs http://goo.gl/iDJ6 | Merges! https://wiki.kubuntu.org/Kubuntu/Ninjas/NattyMerges | Meeting today 16:00UTC [13:55] qmake rocks, doesn't it? [13:56] it rocks so much, I want to strangle it [13:56] ScottK: I don't even know how to find a reference for the qmake language to answer that [13:56] Riddell: I hunted through the online docs and couldn't find anything. [13:57] let's ask in #kde-devel [13:58] ScottK: what is the right flat? [13:58] flag [13:59] -fno-strict-volatile-bitfields [14:01] Riddell: In my patch, I added it in mkspecs/linux-g++/qmake.conf to QMAKE_CFLAGS and QMAKE_CXXFLAGS and it appears in the build log and then vanishes. [14:02] In the mean time, I tried changing that to += and restarted the build to see what happens. [14:02] I have to start over, so it'll be a bit before I know if it matters. === hunger_ is now known as hunger [14:03] apachelogger: how can I resolve the copyright issue? http://revu.ubuntuwire.com/details.py?upid=8693 [14:05] ulysses: grep the source for copyright statements and put those into debian/copyright [14:06] steveire: what's the state of Kontact Mobile? Does it run on normal linux distros? should we be packaging it for kubuntu mobile? [14:07] Riddell: something like? http://pastebin.com/yFVqj0yq [14:07] Riddell: We develop it on normal linux distros. It is desinged for touch interfaces though, not a mouse [14:07] ulysses: that looks good [14:08] steveire: where are the sources? [14:08] There is work going on right now in #kde-mobile towards getting it on meego [14:08] Riddell: kdepim/mobile [14:08] kdepim has to be compiled with DCMAKE_MOBILE_UI or something. [14:09] Possibly kdepimlibs too [14:09] steveire: so when kdepim 4.6 comes out it'll be included in there? [14:09] There are debian packages in branches/work/komo/debian [14:10] Probably not built by default in the kdepim tarball. [14:10] I guess the sources will contain it though, yes [14:10] steveire: but we could enable it then if we wanted to include it with kubuntu mobile? (along with large warnings about tech preview as we do for all kubuntu mobile bits) [14:10] You could, I think, yes [14:11] Let me know if you do that and I'll try it out. [14:11] steveire: is kdepim getting tagged for KDE SC 4.6 beta 2? (i.e. the tagging that was ment to happen yesterday) [14:14] We are aiming to release with 4.6, yes. [14:14] If that didn't happen then I don't know. I'll ask winter. [14:14] well it didn't happen for all of KDE SC [14:15] Oh, I see. [14:15] but presumably if a release manager appears then kdepim will be included in that [14:15] I think so, yes. [14:16] I'm not sure if anything about that has been communicated to the release team. [14:16] I'll try to reach winterz and see. [14:17] Riddell: Is there any specific target HW or hardware form factors for kubuntu mobile? [14:17] steveire: not really, it's been running on N900s but mostly it's a base project that someone would need to complete for a given handset [14:18] but aye, N900 type devices [14:19] Ok, so they're touch kinds of things anyway. [14:19] yes [14:20] Riddell: okay, then two TODOs remained, the get-orig-source target and the splitting of the package to development/library/binary packages [14:42] Riddell: [15:35:59] winter: Is kdepim going to be part of the 4.6 beta 2 tagging? [14:42] [15:38:55] sure. it should be part of the 4.6 beta1 tagging too [14:42] [15:39:03] stephen_laptop: ^ [14:51] steveire_: mm yes I ment beta 1 [15:05] * Riddell hugs agateau for fixing Umbrello [15:22] Riddell: such a big fix :) [15:29] agateau: Do you have any Qt updates this week? I'm preparing an upload today. [15:30] ScottK: no [15:30] OK. Thanks. [15:30] agateau: How's upstreaming going? [15:30] ScottK: not bad, got a first review on irc (by someone outside Nokia) [15:30] Cool. [15:30] ScottK: will update the merge request on monday [15:31] everybody was busy at meego conf, so not much got done from Nokia side :) [15:31] Right. [15:52] intersting [15:52] I have no sound on a dvd [15:52] stupid phonon [15:53] Riddell: can you confirm that dvd playback in dragon does not spit out any audio with phonon-gst? [15:55] apachelogger: well I can't get it past the menu, but there's no audio on the menu when I've tried [15:55] ok [15:56] works in totem [15:56] so either phonon is messing up or dragonplayer [15:59] on a slighlty more positive note [15:59] I can watch a dvd in a qgraphisscene ^^ [16:00] http://aplg.kollide.net/tmp/test.ogv [16:10] steveire_: what is System Settings -> KDE Resources? and how does it relate to Akonadi and Kontact? [16:11] That's the old KResources way to access calendars and contacts, replaced by akonadi [16:12] It shouldn't be shown by default in system settings. [16:12] In theory there's backwards compatibility guarantees saying we can't just rm it [16:14] Riddell: arent we having a meeting? [16:14] was about to ask [16:17] ah yes [16:17] good point [16:18] just to clash with the release team meeting too [16:18] oh [16:18] were late arent we [16:18] where is the meeting? [16:18] here or #ubuntu-meeting? [16:18] Not in #ubuntu-meeting [16:18] lets just trash the release team meeting [16:19] muhahahaha [16:19] hehe [16:19] council ping, neversfelde, apachelogger, JontheEchidna, ScottK [16:19] apachelogger: lets install rekonq on their machines and see them suffer [16:19] Here. [16:19] ahoy ahoy [16:19] here [16:20] anyone here for membership? [16:20] just arrive at home, I need 5 min [16:20] Riddell: I’d ask, but I have to hurry [16:21] bulldog98: next time then? [16:22] no point in hurrying things through anyway [16:22] ScottK wanted to have a review of specs and todo items [16:22] ScottK: able to get us started? [16:22] Yep [16:22] apachelogger: Where was that page? [16:23] Sorry, didn't realize I'd be doing two meetings at once [16:23] https://wiki.kubuntu.org/Kubuntu/UDSNatty [16:23] Riddell: I may apply for membership soon [16:23] however as we noticed yesterday that page does not link to all specs [16:23] How long does that take :) [16:23] and we do not have that many formal specs [16:24] I think the only spec that needs some serious discussion is the one about translations. [16:24] steveire_: if the membership is obviously justified it will be around 5 to 10 minutes of grilling so that the council has some fun [16:24] But I need to make a better wiki page. [16:24] The issues surrounding that one are not just technical, they also have social implications for the community and our relationship with upstream. [16:25] We had a discussion with the LP/translations people at UDS. [16:25] I think the general consensus is that things have gotten better, but there are still issues. [16:26] The main reason for rosetta is to strip per-package translations and put them into per language language packs. [16:26] Since for KDE SC we get them that way already, it's not relevant. [16:27] As it is, it seems that the way KDE ships translations and the way Rosetta handles them are not well suited to each other and the integration will always be fragile and take up developer time to maintian. [16:27] Rosetta offers the ability to continue to improve translations. [16:28] This is not an unmitigated good, since most of the people working on translations in Rosetta are not KDE translators and we have had cases of translations being "improved" is a way that is wrong for KDE. [16:29] Also, now that we have authority from the tech board to ship KDE point releases in -updates we'll be able to ship updated KDE translations post-release too. [16:29] I have asked about being able to lock existing translations for certain packages in Rosetta so that only missing translations could be added. [16:30] This would solve some of the problems and the translations/Rosetta people agree this is a valid request, but not a priority for them to implement. [16:31] Given all this, we need to decide if we want to keep on doing things the way we have or try shipping KDE translations directly for a cycle and see how it goes. [16:31] We seem to have good experience with this from PPA users. [16:31] I think that summarizes it. [16:32] Does anyone else have any relevant points (I have a preference on this, but I'm trying to be balanced) [16:32] so it is not a big problem to switch back to rosetta, after we tried it without? [16:32] * ScottK looks at apachelogger in particular. [16:32] neversfelde: I think we are ~stuck for one cycle, but not for Natty +1. [16:32] k [16:32] Of course it depends on when. [16:32] I'm all in favor of using kde-l10n-* for quality reasons [16:32] Riddell: [16:32] some good news: Phonon-VLC from Git master is rock solid [16:33] There are however concerns. [16:33] from Git Master [16:33] used it for two weeks, not a single crash (!) [16:33] markey: sorry we're in a meeting just now [16:33] consider making it the default backend :) [16:33] ok ok [16:33] Like doing updates becomes incredibly more involving [16:33] apachelogger: How so? [16:34] shipping kde-l10n-xx directly would mean splitting out documentation, working out how to get kde-l10n-xx not stripped, and coding on the language pack generator to make the language packs depend on the correct kde-l10n-xx [16:34] While with launchpad featured translations it is (somewhat) simple, as the translators just needs to change the string in launchpad and pitti needs to roll new language packs. [16:34] If same was to be done in a kde-l10n setup, someone would have to get the source, unpack it, find the relevant file, change the file, write a changelog entry, create a new source, test the source, upload the source, get it through SRU [16:34] but the most imortant thing is I don't thik it would help with the occationally fragile nature of the translations setup since we would still need to keep that for all the other KDE apps and for .desktop files [16:35] so, for us this would mean more work (though of course one can argue that this does not happen that often) [16:35] secondly [16:35] I think the major benefit of switching is social. [16:35] We are insulated from users finding translations worse than what upstream provides. [16:35] Having a half-kde and half-rosetta setup does not improve the general fragility, as jr already pointed out. [16:35] also tangentally relevant is upstream translations have been broken for a cycle and we've had to fix them, they've been shipping the wrong kde pim translations, so it's not like we're the only one to have a record of being problematic with translations [16:35] Although this is rarer than it once was, it's a flash point for people. [16:35] It would still mean that we need to maintain the rosetta stuff. [16:36] Yes, but I think the work to use KDE translations for KDE SC is a one time effort. [16:36] (To that extent I would also mention that we even would have to maintain the patches if we only used upstream translations for everything KDE, because desktop files of non-KDE apps would still have their translations in the lang-packs...) [16:37] ScottK: it is, still someone would have to do it ;) [16:38] apachelogger: That's why shadeslayer is supposed to find more minions, so you have time for complex high level architectural work like this that befits your expertise. [16:38] I'd also like to know what languages have been translated in rosetta for kdelibs/base that havn't been translated upstream [16:38] Riddell: we also had architectural break on the other end of rosetta (export+langpack building), so having less intermediate points where things can break is a good thing [16:38] shadeslayer: you are delaying important things [16:39] wha... [16:39] Riddell: One of the problems we have that relates to this is that upstream doesn't ship translations that are less than some percentage complete. [16:39] So we may have many languages that are partially and differently translated in both systems. [16:40] also worth noting is that rosetta want to do upstream important directory at some point, which means the fragile bit becomes their problem rather than ours [16:40] it is being talked about for like 2 years now [16:40] Riddell: I think at that point and when they have the ability to lock certain templates from changes this decision should be revisted. [16:40] apachelogger: it has been talked about for like 6 years now, but it might actually happen next year [16:40] I don't think we should let what they might do in the future affect what we decide now. [16:41] Riddell: oh, yeah, I mean with some sort of plan that makes sense ;) [16:41] * apachelogger agrees with ScottK [16:41] as a plus point for ScottK's proposal (which seems to have gone entirely off the topic of spec/todo review) it might mean launchpad not bombarding us with e-mails on every upload [16:42] +1000 [16:42] if we decided to use kde-l10n and at some point in the future rosetta grew a sensible thing to use for core kde switching would be very trivial [16:42] (this is one of the specs) [16:42] JontheEchidna: Around? [16:42] (since the architecture for rosetta, as mentioned earlier, needs to remain existing anyway) [16:43] We will also need to deal with strings we add to KDE SC. I think it's been discussed to patch in one template in kde4libs for that. This would still be translated in Rosetta as well. [16:44] ScottK: are you wanting us to vote on this? [16:45] Riddell: I am. [16:45] ScottK: go ahead and make a proposal to vote on then [16:45] I will help implement it if we decide. [16:45] OK [16:46] Proposal: Switch translations for KDE SC for one cycle (as discussed) to see if it produces a better result and reassess at the next UDS. [16:46] how would we review the result? [16:47] I think if it presents problems and causes a lot of work, we'll know. [16:47] For me, if it gave the users the same experience and I didn't mail bombed by Rosetta, I'd call it a win. [16:48] do we know what problems we have in maverick? the only one I know of the lithuanian plurals one [16:48] I think it's difficult to define up front what the exact criteria will be. === hrw is now known as hrw|gone [16:48] I don't know of others. [16:48] In lucid I ended up doing a post RC kdepim upload to un "fix" a translation in kdepim. [16:49] I think most of the benefits will be social with upstream. [16:49] I'm not part of the Kubuntu community as a user, and I think you guys should decide, but whichever decision you take, please ask translators on the mailing list [16:49] dpm: Do you think I captured the points fairly? [16:50] I'm -1 for not reducing the fiddly .pot and .desktop .pot generation and for apparantly not having a current problem to fix and not having an overview of what languages we'd lose because they're in rosetta and not upstream [16:51] * apachelogger notes that langauges being in rosetta and not upstream is a problem right there [16:52] I'm +1 for not having to worry about translators in Rosetta changing existing translations. [16:52] ScottK, yes, although I believe it is quite difficult to review upstream social impact, "before and after". We haven't had complaints on translations for a while, afaik, and I don't think we'd get them after a potential switch, either, unless things would go horribly wrong [16:52] dpm: I agree it's not an easy thing to know. [16:52] apachelogger: it is but you can't blame rosetta for offering a nicer UI than upstream (of course some people think the opposite is true) [16:53] (if we had template locking now, I wouldn't have brought this up) [16:53] * ScottK looks at apachelogger, neversfelde, and JontheEchidna to vote. [16:53] Riddell: no, I blame rosetta for not offering a nicer solution than not upstreaming at all [16:53] so that's one of my concerns, although the biggest one is pretty please, talk to translators and include them in the conversations [16:53] I can help with that if you guys want [16:54] hmm [16:55] and just to bring some more info in the discussion, here's the status of LP Translations development right now, for anyone interested: [16:55] https://lists.launchpad.net/launchpad-dev/msg05638.html [16:57] +(1/2) since template locking is important, yet not in sight, since upstreaming is important, yet not in sight, since there have been problems ever since rosetta was introduced ... however I am not entirely sure the effort would be worth the time (fortunately enough, unlike rosetta support it does not require constant maintenance) [16:58] also this vote is bound to having translators made well aware of why the decision was made and understand and agree with the reasoning [16:58] o/ [16:58] I am not sure how to vote, I think I first should have a deeper understanding about this. take it as a 0. If we are 2 : 2 we'll have to wait until I can decide :) [16:58] sorry about lateness [16:59] dpm: I don't see the template locking on that roadmap. [16:59] (i.e. if they disagree our own arguments probably have not been sound) [17:00] ScottK: can you chase up votes from the other council members [17:00] Riddell: I can. [17:00] then we'll need to work out what happens if it's obviously split [17:01] Yes. [17:01] we have it written down somewhere, from some past UDS [17:01] apachelogger: Can you take an action to pursue talking with Rosetta and KDE translators? [17:01] I'd say we should move on. [17:01] cando [17:01] suppose [17:01] shadeslayer: ^ work for you [17:02] Riddell: Do you know if the work described in https://blueprints.edge.launchpad.net/ubuntu/+spec/appdevs-dx-n-qt-support is upstreamable? [17:02] That's my primary concern with that one. [17:03] ScottK: it is upstream [17:03] they're the ones who discussed it and will do it [17:03] with help from Duncan and his team [17:03] Riddell: They being Nokia? [17:03] yes [17:03] Sounds good then. [17:03] ScottK, it isn't there, and it is not on sight. To be honest, I believe the problems with modifying translations is no longer as important as it was before. Some years ago most of the translations teams were Open, nowadays there is a policy that they should be moderated. They act as reviewer teams and should not modify upstream strings, and this has improved a lot, apart from the fact that several teams work both upstream and downstream - but granted, [17:03] you'll still get some unwanted changes, to be fair. In short, my opinion is that template locking is no longer as relevant as it was before. [17:03] so hopefully we'll have nice touch support in Qt 4.8 [17:04] but anyway, just replied for the sake of completeness, please move on :) [17:05] Does anyone else have spec questions? [17:05] why did fluffy not get spec'd? :P [17:05] apachelogger: You didn't assign shadeslayer to write the spec. [17:05] shadeslayer: ^ yet more work for you [17:05] What was the conclusion on https://blueprints.launchpad.net/ubuntu/+spec/appdevs-kubuntu-n-ubuntu-one ? [17:05] * ScottK missed that one [17:06] I think they agreed to have a semi-sane policy for libraries and third party translators [17:06] but we'll have to see if they follow it [17:06] Is anyone volunteered to work on the project? [17:06] I'm being pinged by ubuntu one as we chat about how ubuntu sso should be modularied to allow kde/gnome support in it [17:06] also stuff of ubuntone-kde is salvageable if only someone were to step up and do magic [17:07] it'll need a volunteer to get the ubuntu one kde bits complete and nobody has so far volunteered [17:07] I think that one should just stay as it is (and not get approved) until there is some movement on actually doing it. [17:08] Riddell: Did you find a time to sit down with padams yet about https://blueprints.launchpad.net/ubuntu/+spec/packageselection-server-n-kolab ? [17:08] yes [17:08] yes to the above not getting approved [17:08] How'd that go? [17:08] Ah. [17:08] no I've not had a meeting with padams, I'll probably ping him shortly to see if he's going to buy me more pizza [17:09] lol [17:09] OK. I think that one we should hold off a bit on until we see what upstream support we have. [17:10] AFAIK, all the othes are fine. [17:10] they'll have their two day testing suite running but I'm not sure what the output of that is or what we do if it shows up problems [17:11] any thoughts on the big Todo list? https://wiki.kubuntu.org/Kubuntu/Todo [17:12] needs more assignments [17:13] yes but assignments can act as blockers so don't go assiging unless you're sure they'll follow through [17:14] Looks fine to me. [17:14] KDE stable release updates policy is done isn't it? [17:14] yes [17:14] Just need JontheEchidna to upload 4.4.5 to lucid-proposed. [17:14] neversfelde: no but it's not needed now we have "(re-)propose to tech board to include updates in -updates, QA'd in PPA first" [17:15] ok [17:17] groovy, shall we move on [17:17] or do we need to vote on the specs and todo list? [17:17] I think we should have a vote. [17:17] [VOTE] agree to follow the specs and todo list for Natty https://wiki.kubuntu.org/Kubuntu/Todo https://wiki.kubuntu.org/Kubuntu/UDSNatty [17:18] I'm +1 [17:18] +1 [17:18] Proposal: Approve the specs on https://wiki.kubuntu.org/Kubuntu/UDSNatty except for Ubuntu One an Kolab. [17:18] +q [17:18]