=== zz_Jacky_ is now known as jackyalcine === jackyalcine is now known as Jacky_ === Jacky_ is now known as zz_Jacky_ === zz_Jacky_ is now known as jackyalcine === jackyalcine is now known as Jacky_ === jbicha is now known as Guest80174 === Guest80174 is now known as jbicha_ === Jacky_ is now known as zz_Jacky_ === zz_Jacky_ is now known as jackyalcine === jackyalcine is now known as Jacky_ === m_conley_away is now known as m_conley [05:28] tkamppeter_: "Only long keyids (v4, 160bit) are supported", ah, that indeed explains it [05:28] Good morning [05:29] pitti, good morning :) [05:29] larsu: oh right -- crazy times for you now :) [05:29] pitti, ya, at least I see you get up now! [05:30] larsu_: ping [05:31] attente: pong === Jacky_ is now known as zz_Jacky_ === zz_Jacky_ is now known as jackyalcine === m_conley is now known as m_conley_away [06:15] Good Morning [06:23] good morning [06:38] good morning didrocks :) [06:39] hey BigWhale, how are you? [06:39] I'm up from 6am ... that's how I am :)) [06:40] Right now contemplating what is the acceptable number of bugs for a 'stable' release. :) [06:42] heh ;) [06:46] That's not funny! :P [06:46] :)) [06:49] it is, before coffee and you start to realize what this really means ;) [06:53] I don't drink coffe. :/ [06:54] tea works for caffein ;) [07:34] good morning [07:34] hmmmmmmm... what is the Vala equivalent of python's unittest.assertRaises? [07:39] hey jibel, morning/evening robru! [07:40] hey didrocks ! [07:40] bonjour didrocks [07:44] Which window manager is used in gnome-session-fallback? [07:49] metacity [07:50] is there a way to turn on compositing in metacity? [07:51] or make a window transparent in non-compositing WM's? [07:52] BigWhale: gsettings set org.gnome.metacity compositing-manager true [07:52] btw there is also gnome-fallback-comits session [07:52] *gnome-fallback-compiz [07:53] mitya57, thanks. [07:54] Why is it off anyway? [07:54] performance wise? [07:55] BigWhale: doesn't work well if you don't have accelerated drivers [07:55] still work, but can be slower and have artefacts === jackyalcine is now known as zz_jackyalcine [09:04] friiiiiday [09:09] yeeeeep ;) [09:10] qtdays! [09:11] O RLY [09:24] I abandoned Qt when KDE4 was released for the first time. :) [09:45] didrocks: what what? [09:45] mpt: got another potentially not helpful update-manager dialog today... http://popey.com/~alan/untrusted.png "This requires installing packages from unauthenticated sources" (I know the reason, I have a PPA which I didn't add the key for) [09:46] good morning [09:46] hey Riddell, sorry, was disconnected, didn't receive your first message :) [09:46] mpt: if you run "apt-get upgrade" then the similar warning is presented as just that, a warning, with the option of pressing "yes" to allow it. update manager offers no option to ignore the warning. [09:46] (sharing screen in hangout made xorg crashing) [09:46] didrocks: I only got "qtdays" does this mean you have some plans for qt today? [09:47] Riddell: the plan than Mirv talk to you about with Qt 5 [09:47] Riddell: so qtchooser + qt4 compatible with qt5 paths [09:47] and we start to upload an initial version qt5, reviewing under way [09:47] didrocks: I'm wanting to wait until KDE 4.10 is in before that gets uploaded [09:47] (the version that was acked with debian as well) [09:47] cos I suspect they'll clash somewhat [09:48] Riddell: you mean, the qt5 part? [09:48] didrocks: well qtchooser and qt4-x11 changes, but I think qt5 will depend on that [09:48] Riddell: the qt4 with qtchooser it uploaded (qt4 in binary NEW I guess for the -default package) and qtchooser in source NEW [09:49] is* [09:49] didrocks: ah good old New queue :) [09:49] heh :) [09:49] didrocks: KDE SC 4.10 is all done except for smelly old powerpc being slow [09:50] Riddell: ah ok, no new package? I doubt qt4-x11 will be built on powerpc before the kde pieces on powerpc are built? [09:50] no new in 4.10 [09:51] ok, I thought that's what you meant once you wanted KDE 4.10 first ;) so we're all good [09:51] Riddell: qt4-x11 won't be publish anyway before the new -default package is NEWed [09:51] and I guess powerpc will finish before qt4-x11 powerpc starts even [09:51] finished* [09:51] let's keep qtchooser in source NEW as well until the powerpc builds ends [09:52] Riddell: works for you? [09:52] didrocks: qt4 seems to have started on powerpc, how did it skip the queue?! [09:53] Riddell: hum, you're right, crap :/ is it a priority main/universe? [09:53] Riddell: I didn't request anything FYI, no score bump [09:53] didrocks: oh that's probably it [09:53] Riddell: normally, headers are not impacted, it's just binaries that are moving [09:53] Riddell: so, hopefully, you can still publish kde, even on powerpc if built against the new qt4-x11 [09:54] you could have someone kill the build [09:54] didrocks: since powerpc is not something we should care about I wonder if it's sensible to just tell the proposed migration to ignore the kde packages [09:54] popey, bug report please [09:54] Riddell: I would +1 on that TBH, but I guess that the tool won't be able to copy powerpc after the fact and will rebuilt it [09:55] or just do what Laney is proposing, killing the build [09:55] the qt build? [09:55] for powerpc [09:55] ok I'll ask for that [09:55] why is it a problem? [09:56] surely any problem you'll hit at the next upload anyway [09:56] Laney: it's not really, we are just moving some binaries and renaming them for being compatible with the incoming qt5 [09:56] so no header change [09:56] Laney: but Riddell wants to publish KDE 4.10 first to have a separate change tests, I guess [09:56] mpt: ok [09:56] (understandbly, don't mix potential issues ;)) === vrruiz_ is now known as rvr_ [10:02] Riddell: which package should I look at to tell "yeah, everything is built on powerpc"? [10:02] everything == KDE 4.10 [10:03] didrocks: everything beginning with a k? :) [10:03] Riddell: well, do you have a control tower for that? ;-) [10:04] didrocks: what's one of those? [10:04] mpt done, bug 1119247 [10:04] Launchpad bug 1119247 in update-manager (Ubuntu) ""This requires installing packages from unauthenticated sources" warning not useful" [Undecided,New] https://launchpad.net/bugs/1119247 [10:04] Riddell: I meant, do you have a one single page to check that powerpc on everything starting with a k ended? [10:04] * didrocks wonders why again he can't access to https://launchpad.net/builders [10:04] didrocks: I'm watching http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html [10:05] although haskall is getting in the way of making it quick to read [10:05] Riddell: oh, good hint! [10:05] Riddell: thanks, will look at that :) [10:05] so many haskell* package, I blame Laney! [10:06] muhahah [10:07] :p [10:08] didrocks: private receipe build going on so untul thats gone you wont be able to see it [10:08] czajkowski: isn't it written normally just "private build" for those? [10:09] I saw that sometimes, without details, just "private build" [10:09] didrocks: sometimes but wgrants says this is normal [10:09] that's private package builds [10:09] slightly different [10:09] hum, interested in more details now ;) [10:10] didrocks: poke wgrant :) [10:10] there's probably a bug on it [10:10] https://bugs.launchpad.net/launchpad/+bug/760303 [10:10] Ubuntu bug 760303 in Launchpad itself "builders page inaccessible if a private recipe build is building" [High,Triaged] [10:11] heh, will do thanks czajkowski, Laney ;) [10:11] really need to remove launchpad as a highlight [10:12] lies, your interventions are helpful [10:15] indeed, they are :) [10:24] chrisccoulson, hey [10:25] hi seb128, how are you? [10:25] chrisccoulson, I'm good thanks, how are you? [10:25] happy friday ;-) [10:25] seb128, yeah, not too bad thanks [10:25] chrisccoulson, did you see my libdbusmenu ping yesterday afternoon? [10:25] bah, friday, i could do with an extra day in the week ;) [10:26] seb128, what sort of testcase are you after? [10:26] chrisccoulson, something that could do a SRU testcase :p [10:26] seb128, ah, i did wonder :) [10:26] I want to SRU the fixes, I'm just unsure that the SRU team will like "run firefox under valgrind" [10:26] seb128, yeah, i'll see if i can get a testcase that doesn't involve firefox [10:27] thanks! [10:27] you need a special build to run that under valgrind in any case [10:27] don't spend too much work on it anyway [10:27] if we don't have a testcase I will go the "just make sure nothing behave wrongly, watch $program memory usage" [10:27] way [11:04] gruh [11:04] didrocks: so this does introduce failures [11:05] the unversioned qmake seems to have gone/moved [11:07] * didrocks looks for the merge request [11:07] Laney: do you have a link for the failure? [11:07] seems from the changelog that I have to BD on qt4-default now? [11:07] it was a local build [11:08] qmake [long list of options] fa [11:08] iled to to execute: No such file or directory [11:08] Laney: ah right, you need qt4-default or qtchooser to chose one [11:09] the -dev package dep on qt4-default IIRC [11:09] let me check [11:10] so qt5 will start installing just `qmake' I guess? is that expected to work for most packages? [11:12] I think I'll pass --buildsystem=qmake_qt4 [11:14] sorry, was another chat :) [11:15] heh [11:15] one sec, checking something [11:15] indeed, this is an issue in a builder [11:15] I think libqt4-dev should dep on libqt4-default [11:16] or [11:16] hum, not that easy :) [11:16] because qt4-default and qt5-default conflicts [11:16] qtchooser is the tool to tell "I'm using those dev tools" [11:16] alternatives? [11:16] being make_qt4 [11:16] or qmake_qt5 [11:16] Laney: debian didn't want alternatives [11:17] hmm [11:17] Laney: they prefered this tool, which is what upstream is supportive for [11:17] maybe Mirv can give us an hint, he work with them more than I [11:22] yes, upstream recommended and Debian wanted qtchooser, making it unnecessary to continuing patching the sources adding suffixes everywhere and handling alternatives [11:23] do you expect continued build failures due to this? [11:23] Mirv: the question I guess is for a simple app, they will build-dep on libqt4-dev and not qt4-default [11:23] it has the new requirement that everything that builds against Qt4 needs to build-dep on qt4-default [11:24] I think this ought to be communicated [11:24] shouldn't rather we have libqt4-dev dep on qt4-default | qt-default [11:24] and qt4-default provides: qt-default? [11:24] (and something similar for qt5) [11:25] that could be an option. I tried to initiate ideas with pkg-kde but didn't get the topic going. [11:25] Laney: am I crazy or this proposal makes sense to you? ^ [11:25] (if so, I would propose we fix that right away) [11:27] I think so, but I don't know the area well enough to be aware of any gotchas [11:27] I'm starting a parallel discussion at #debian-qt-kde (oftc) [11:27] Mirv: if I have qt4-default installed [11:27] and I run qtchooser [11:27] I can set qt5 as default, right? [11:27] which screwing up the packages? [11:28] without* [11:28] didrocks: yes, you can use any of the methods like export QT_SELECT=qt5 [11:28] but only one can be the real default without any parameters or env vars [11:28] Mirv: ok, tell me how it goes on #debian-qt-kde, I think we should do those for qt4 before the week-end [11:28] let's see if anyone is around [11:28] thanks :) === q__ is now known as Phryq [11:31] unblocking glib; I don't see any new failures from it [11:32] heya guys. Is this a room where Ubuntu desktop-users can ask for help? [11:38] Phryq, no, this channel is for Ubuntu developers. You can find IRC support and other forums at . [11:39] And a channel list at . [11:42] Phryq: if you're looking for irc support head to #ubuntu [11:47] pitti: Hi Martin; thanks for sponsoring bug 1103547. [11:47] Launchpad bug 1103547 in language-selector (Ubuntu) "drag and drop does not work language support not complete" [Low,In progress] https://launchpad.net/bugs/1103547 [11:48] didrocks: some talk now how most packages should be using qmake-qt4 which is still available.. [11:48] was there some package that already failed to build? [11:48] Mirv: that's not what debhelper calls [11:48] see /usr/share/perl5/Debian/Debhelper/Buildsystem/qmake.pm [11:48] hey GunnarHj, you're welcome! thanks for the fisx [11:48] pitti: Just curious about why you use set() instead of 'the good old' []. Is it about efficiency? [11:50] GunnarHj: no, but because missing() was previously returning a set [11:50] Laney: thanks, using that information [11:50] and the new function turned a set into a list [11:50] GunnarHj: ^ which broke API; my new test case complained about taht [11:50] Mirv: I don't know whether debhelper could in theory be improved to detect which qmake to call [11:50] pitti: Aha, then I understand. Thanks for explaining. [11:51] you might want to use codesearch.debian.net to see how many packages explicitly call unversioned qmake too [11:51] < pinotree> use qmake_qt4, not that [11:51] that's fine to say, but reality might be different [11:51] the fact is debhelper uses that by default so I expect packages do rely on it [11:52] hey Laney [11:52] Laney: I don't see any autopkgtest failures which are due to glib, did you? [11:53] pitti: no - I already unblocked it [11:54] yay [11:55] and: trying: glib2.0 [11:55] accepted: glib2.0 [11:55] \o/ === vrruiz_ is now known as rvr_ [11:59] I'm also mentioning that rcc tool didn't have the suffix in Qt4 [12:00] I'm having a bit of a problem... I can't log in to my account on my PC [12:00] which means any package using rcc would break without qt4-default [12:00] it accepts my password, but then goes back to lightdm [12:00] I'm running raring [12:00] SuperMatt, hey, try #ubuntu+1 for user support [12:00] righto [12:09] didrocks: discussion stopped for a moment, but since all in Qt5 is NEW qt5-default requirement would be fine (and we also use it already). I'm trying to get agreement first if qt4-default dependency in libqt4-dev is acceptable. for rcc and debhelper use it seems obvious to me. [12:10] Mirv: thanks for following it up [12:10] Riddell: ^ you might want to be aware of this discussion [12:11] there is also the option of we just doing it for libqt4-dev, since if Debian decides not to follow that route and fixes all Qt4 apps not to require qt4-default, we can sync [12:11] we're not seeing uploads in Debian any time soon probably anyway because of the upcoming release and NEW queue being deprioritized there [12:12] Mirv: ok, thanks :) [12:12] Mirv: so we won't change qt5-default [12:12] just keep compatibility for qt4, right? [12:12] didrocks: actually for the time being I don't see any downsides of we doing the libqt4-dev dep on qt4-default thing, since it's transparent to drop if everything actually works without? [12:13] Mirv: right, want to do it? [12:13] didrocks: sounds like that currently [12:13] or I can [12:13] actually [12:13] didrocks: well, feel free, I still haven't had my lunch :( [12:13] Mirv: sure, enjoy your lunch then :) [12:13] the hangout that was supposed to be later started an hour ago [12:13] I really try now :) [12:13] urgh, good luck! :) [12:14] Laney: thanks for spotting it! I'm sure there are still some cases in qtchooser that is still not covered, but at least, that shouldn't break the build of qt4 apps [12:14] hmm [12:14] I'm adding as well a recommends from qt4-default on libqt4-dev [12:14] so then you won't be able to develop for qt4 without having it as default [12:15] so that if the way in the future is to use qt5-default, people don't mix it [12:15] i.e. installing qt5-default will actually uninstall libqt4-dev [12:15] is that ok? [12:15] ah, good point [12:15] hum… [12:16] Laney: ok, I didn't follow this story from the beginning, we can workaround with a recommends for now [12:16] buildds don't install those [12:16] really? I never knew that [12:16] hemf [12:17] Perhaps Depends: qt4-default | qt-default and qt5-default Provides: qt-default is the way to go [12:17] so only the qt5-default providing qt-default as well would allow full conistallability [12:17] Laney: that was my proposal [12:17] 12:24:14 didrocks | shouldn't rather we have libqt4-dev dep on qt4-default | qt-default [12:17] yeah [12:17] yeah, let's do that [12:18] but we were coming around to not changing qt5 [12:18] let's makes it provide qt-default [12:18] I can't currently think of a solution where that's possible though [12:18] one person doesn't like that because qt5-default shouldn't be able to fulfill libqt4-dev dependency, but even though that's a cosmetic issue we don't yet even have the consensus of accepting qt4-default dependency in libqt4-dev, so that's only the next debate [12:18] sorry, I go now, I shouldn't be here.. [12:19] Laney: yep, I think that the qtchooser thing was half-thought, I don't even know how if it handles well manually changing the default when one default package is installed [12:19] well, you can think of that dependency as saying that you get qt4 as default by default but if you know what you're doing you can override that [12:19] should really have been an alternative, not sure why it was rejected [12:19] anyway, let's avoid breaking for now :) [12:20] if Debian decides to reject it it wouldn't be too hard to fix up the packages [12:20] yep :) [12:23] ok, it's ready here, waiting for the powerpc build for k* to finish first [12:24] Laney: mind having a look? lp:~kubuntu-packagers/kubuntu-packaging/qt/, rev 349 [12:25] getting [12:26] looks right [12:26] Laney: thanks ;) [12:26] reuploading qt5 in NEW [12:32] didrocks: it seems that for now, the Debian qt4 packaging will not be changed, ie. "see what breaks" and even that is only at some point when those start to be uploaded [12:33] then if it needs to be added, the "qt4-default | qt-default" libqt4-dev dep is more likely than "qt4-default" (where qt5-default would force uninstallation of libqt4-dev) since only one opposes it [12:34] Mirv: yeah, I've prepared that for qt4 (waiting for the k* to be built on powerpc) and uploaded the new qt5 with the provides [12:35] sounds good === zz_jackyalcine is now known as jackyalcine === jackyalcine is now known as Jacky_ === Jacky_ is now known as zz_jackyalcine === larsu_ is now known as larsu [13:27] ah, nice, amliit is in the archive ... [13:27] *maliit [13:28] but it doesnt buy us any ram :( [13:29] Laney, is there any config file or so for it ? [13:29] its pretty small [13:30] seb128, did you set up a meeting agenda for today ? (i was pondering to send an announcement and link to it) [13:31] ogra_, no, do you have anything you would like to get on an agenda? should we start creating a wiki page for that? [13:31] ogra_, I can send the reminder if you want [13:31] that would be fine, no, nothing for the agenda, you said you wanted one this week, so i thought i'd ask [13:32] yeah, and I though about it this morning and I've nothing to put on it :p [13:33] heh, same here [13:33] ogra_, I can create a wiki page anyway so we have one and maybe we manage to put stuff on it next time [13:33] ogra_, should I send the reminder to ubuntu-devel@ then? [13:33] so lets ignore the agenda (and a wiki for it) until we have something for it [13:33] yeah, i'll post it to G+ then [13:33] thanks [13:34] seb128, hi :) [13:35] ricotz, hey [13:38] seb128, i am looking into a vala patch http://people.ubuntu.com/~ricotz/pkg/vala-0.18_0.18.1-0ubuntu4.debdiff which is needed with the next gobject-introspection release [13:39] pitti, ^ do you know about that? g-i is your domain ;-) [13:39] seb128, weirdly i am running into build issues currently, will check this out first [13:40] vapigen will fail/error-out on this new parameter otherwise [13:42] seb128, ah, since the vala builds directly from the c source it isnt that easy to patch [13:43] ricotz, you probably want to include the diff to the .c as well [13:43] seb128, yes, or depend on valac again [13:43] no, please no circular depends [13:43] i know, it was annoying in the past [13:45] seb128: hey; reading (back from lunch) [13:46] ricotz, seb128: ah, that's from Colin Walters, so seems fine; thanks for the heads-up, I wasn't aware that .girs are going to get the self argument [14:01] seb128, pitti, http://people.ubuntu.com/~ricotz/pkg/vala-0.18_0.18.1-0ubuntu4.debdiff [14:02] eek [14:02] ricotz: our vala package doesn't build-dep on vala to rebuild itself? [14:02] pitti, no, not anymore [14:03] but *shrug*, it's ACN upstream, so will hopefully disappear soon [14:04] pitti, yeah, hopefully [14:04] although there isnt even a 0.19.x release yet [14:07] i hope someone likes to sponsor it ;) [14:08] ricotz, it doesn't seem to be in the sponsoring queue? [14:08] not going to be sponsored if it's not in there... [14:08] ricotz: ah, sure, I'll upload it [14:08] seb128, ah, i meant upload it [14:09] pitti, thanks! [14:09] ricotz, not likely to happen either (vala 0.19) if somebody doesn't put an update up for sponsoring [14:09] ricotz, currently desktop team has other priorities than packaging unstable series [14:09] ogra_, https://lists.ubuntu.com/archives/ubuntu-devel/2013-February/036448.html [14:09] seb128: c'est d'accord, j'ai le telecharge [14:10] ..chargé [14:10] pitti, vala 0.19 ? [14:10] (^ je crois?) [14:10] seb128: no, ricotz's 0.18 patch [14:10] seb128, yes, i was speaking of upstream, jbuergi seems busy [14:10] pitti, oh, ok [14:10] pitti, "télécharge" ;-) [14:10] is canonical still tracking one version behind gnome? [14:10] seb128: "j'ai le téléchargé"? [14:11] SuperMatt, canonical->ubuntu and define "one version behind" and "still" [14:11] SuperMatt, since this cycle we decided to stay on stable GNOME series rather than track unstable ones [14:11] SuperMatt: yeah, blocked by not having logind and also we decided to stay at 3.6 feature-wise for this cycle [14:11] gotcha [14:11] seb128, just to clarify this patch is only present in vala master which hasnt seen a release this cycle yet [14:12] so essentially no gnome 3.8 in raring [14:12] pitti, "je l'ai téléchargé" if it's done, "je le télécharge" if you are doing it [14:12] pitti, french is hard? ;-) [14:12] SuperMatt, right, and no gnome 3.10 next cycle [14:12] seb128: ah, the "le" goes before the "have" even, merci [14:13] pitti, de rien! [14:13] seb128, was there a conclusion about gtk+ 3.7.x? [14:13] seb128: I was applying German word order [14:13] ricotz, it might happen if somebody file the MIR for harfbuzz and figure the graphite2 depends and work then on the updates [14:14] ricotz, not likely to happen without somebody out of canonical-desktop-team helping though [14:14] seb128, the packages are in gnome3-staging [14:14] so up to you and the other gnome3 ppa guys to see if you prefer to maintain it in a ppa or try to get it in the archvie [14:14] ricotz, that doesn't solve the MIR issue :p [14:15] yeah, just the harfbuzz mir then [14:15] and the graphite2 thing [14:15] this dep can be dropped [14:15] and somebody to submit merge requests to review for those updates [14:15] I don't plan to go try to figure out what is happening in ppas [14:15] ogra_: config file? what for? Not that I'm aware of [14:15] seb128, i see [14:15] pitti, yeah, I agree with you, german words order is weird, I always though so :p [14:16] * seb128 hugs pitti [14:16] * pitti tu donne une accolade aussi [14:16] "te" [14:16] argh! [14:16] shrug, it's another of those days were nothing is moving out of proposed thanks to powerpc [14:16] hate powerpc [14:17] FTBFS or slow? [14:17] 6 hours backlog [14:17] well it's getting better, but the source I was looking to has been uploaded 6 hours ago and is set to build in 15 min [14:21] the new buildd is pretty decent I've found === Ursinha is now known as Ursinha-afk === tkamppeter_ is now known as tkamppeter [14:34] Laney, well, to define that it is at a usable size [14:35] Laney, in landsacep it only occupies about 1/3 of the screen widht ... in portrait it is so small that i cant really use it [14:35] *landscape === zz_jackyalcine is now known as jackyalcine [14:39] seb128: mostly due to private jobs still building on powerpc.... [14:41] ogra_: I'm sure things will improve wrt the tablet usecase over time [14:41] we'll be able to have the nemo keyboard once Qt5 exists [14:41] Laney, sure, i was just wondering if we could replace onboard ... [14:42] not that I know if it's better or worse [14:42] I wouldn't recommend that just now [14:42] but the RAM usage seems to be the same and the actual kbd isnt really usable that way yet [14:42] laney@bisquicks:~$ htop [14:42] No command 'htop' found, did you mean: Command 'hatop' from package 'hatop' (universe) [14:42] err [14:42] its doesnt seem to buy us anything over onboard atm === Ursinha-afk is now known as Ursinha [14:43] uh, what ? === Ursinha is now known as Guest65450 [14:43] I didn't suggest switching it just yet [14:43] we should wait and see what happens, but now it's in the archive so people can play with it [14:46] yeah === m_conley_away is now known as m_conley === Ursinha_ is now known as Ursinha === jbicha_ is now known as jbicha === sil2100_ is now known as sil2100 [16:56] seb128: still there? [16:56] GunnarHj, hey, sort of [16:57] seb128: Hi Sebastien! Do you have time to sponsor the latest MP at bug 1103547? It's a regression fix, and we may be spared a few bug reports if it makes it into the archive fast. [16:57] Launchpad bug 1103547 in language-selector (Ubuntu) "drag and drop does not work language support not complete" [High,In progress] https://launchpad.net/bugs/1103547 [16:57] GunnarHj, still there for 1.5 hours but with a backlog of work worth 3 hours :p [16:57] seb128: sorry ... [16:57] GunnarHj, sure, that seems easy enough [16:57]