[05:22] Mirv: hey, I'm around if any packaging review needed :) === tvoss|eod is now known as tvoss [05:23] morning didrocks! upower in system-settings http://10.97.0.1:8080/view/cu2d/view/Head/view/Settings/job/cu2d-settings-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-system-settings_0.1+13.10.20130813-0ubuntu1.diff + new mir packages in platform-api http://10.97.0.1:8080/view/cu2d/view/Head/view/Platform/job/cu2d-platform-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_platform-api_0.18.3+13.10.20130813-0ubunt [05:24] Mirv: good morning! system-settings + mir: ack ;) [05:24] Mirv: will you look at u-s-c and apps? we have 35 minutes to figure out what's wrong before next daily release :) [05:25] platform, not mir :) mirslave seems to be depending on this. [05:25] Mirv: sorry, I meant, platform :) [05:25] unity-system-compositor:i386 Depends on libmirserver1 [05:25] so after platform gets them to NEW it'd be resolved? [05:26] no actually different package [05:26] Mirv: no need for NEW? (normally yeah, binary NEW, but we bypass that with daily releases) [05:26] yeah, it's the AP tests that are failing [05:26] like a lot of them [05:26] the whole line is about strict version dependency unity-system-compositor:i386 Depends on libmirserver1 [ i386 ] < none -> 0.0.9+13.10.20130813-0ubuntu1 > ( libs ) (= 0.0.9+13.10.20130812.4-0ubuntu1) can't be satisfied! [05:27] didrocks: platform has the new binary packages libubuntu-application-api-mirserver1 + libubuntu-application-api-mirclient1, but the whitelist was only for new source packages? [05:28] apps on the other hand has gathered a lot of gstreamer/libav dependencies [05:28] Mirv: oh yeah, the whitelist is only source packages [05:28] Mirv: yeah, I just checked them, they seem ok (almost all in main). I just wonder about gstreamer0.10-ffmpeg [05:28] Mirv: you know, ffmepg isn't really allowed everywhere [05:29] Mirv: mind poking upstream about it? (not blocking on that, but let's do that preventively) [05:29] and note in the "not blocking release part" [05:29] Mirv: btw, not sure you noted, but you have the dependency chain before the + in the logs [05:29] like: [05:29] /var/log/upstart/otto-setup.log: Installing gstreamer0.10-ffmpeg as Depends of gallery-app [05:29] /var/log/upstart/otto-setup.log: Installing libavcodec53 as Depends of gstreamer0.10-ffmpeg [05:29] /var/log/upstart/otto-setup.log: Installing libavutil51 as Depends of libavcodec53 [05:30] it helps to know what's pulling the different components :) [05:31] didrocks: ok, poking and noting, meanwhile https://code.launchpad.net/~timo-jyrinki/cupstream2distro-config/apps_gstreamer_libav/+merge/179848 [05:32] Mirv: +1, please merge :) [05:32] Mirv: btw, if you have any idea on how we can make this list more easy to deal with… [05:32] Mirv: it's the biggest part I'm not happy about, but I don't know how we can deal with that ensuring the same security in term of detecting transitions [05:33] (and packages that we shouldn't dep on) [05:33] the only piece of improvment I guess is to add to the dep list the stack we depend on package list as well [05:34] yes it's a bit ugly. diff:s would be easier with newlines, but then it'd take even more space [05:34] ok apps redeployed, shall I rerun check or let the next run handle it? [05:37] didrocks: what do you think about these repeated unity7 AP problems? now I haven't seen the aborted AP sessions, but still differentiation. there was a successful (marked as such) check run during the night, and the diff against the new one is http://pastebin.ubuntu.com/5979939/ [05:37] Mirv: next run is in 20 minutes, I'm fine with waiting [05:37] should we start the familiar-from-the-past manual testing on the differing tests and forcing publication if no problems found? [05:37] Mirv: I guess we shouldn't do the manual testing anymore as long as there is no urgency [05:37] Mirv: juste poke upstream + the manager [05:38] and write in the list [05:38] right. with the webapps now functioning, autopublishing should happen every now and then. [05:38] Mirv: we have enough to do TBH without adding the manual testing :) [05:38] yeah ;) [05:38] Mirv: can you start with the list of mirslaves unity AP tests failing? [05:38] Mirv: I think that list is urgent [05:38] (because mir and platform-api are blocked in -proposed as long as those are not addressed) [05:41] didrocks: I don't see the failing AP tests? just the dependency problem. [05:41] http://10.97.0.1:8080/job/autopilot-saucy-daily_release/950/label=autopilot-ati/console etc [05:42] Mirv: argh [05:42] Mirv: I've been trapped by the jenkins ui [05:42] there was a new mir snapshot that go tin two hours ago [05:42] I guess it's a sign for coffee needed :p [05:42] didrocks: hehe :) that's not a miracle, the ui is what it is [05:42] Mirv: don't tell me :) [05:43] I'd think the dependency problem would resolve itself now that the new mir is built [05:43] Mirv: it's interesting in fact [05:43] mirslaves deps on mir [05:44] so normally mir finished before mirslaves start [05:44] and is published [05:44] Mirv: maybe we can quickly run mirslaves? [05:44] (the tests are taking 10 minutes, should just be before the tick) [05:44] sure we can, just foo run? [05:45] yeah [05:45] ok, it's running [05:45] thanks Mirv :) [05:45] I propose we trademark the "foo run" :) [05:46] you're welcome [05:46] ok, passed the installation step, I think we had a publisher mismatch possibly [05:46] http://10.97.0.1:8080/view/cu2d/view/Head/view/All/job/cu2d-build_all-head/lastSuccessfulBuild/console [05:47] as you can see mir is run in the first pass [05:47] and mirslave in the second [05:47] __________ divide dependencies [05:47] (there is no more manual scheduling) [06:43] p/quit [07:28] i guess we're not going to see g-c-c/g-s-d 3.8.x in saucy? [07:28] tjaalton: I think it's a question for seb128 (he will be around late) [07:29] didrocks: ok [07:32] tjaalton, g-s-d yes, g-c-c probably not [07:33] darkxst: alright [07:33] its still blocked by the ibus/keyboard-indicator stuff though [07:40] hmm I think the new wacom stuff needs g-c-c 3.8 too, but oh well [07:48] didrocks: apps would be ready with the ffmpeg packaging addition http://10.97.0.1:8080/view/cu2d/view/Head/view/Apps/job/cu2d-apps-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_gallery-app_0.0.67+13.10.20130813.1-0ubuntu1.diff [07:48] top [07:49] Mirv: ok, +1 for publishing, did you ping upstream? (cc Pat maybe?) [07:49] Mirv: will start on qt3d & co in a few minutes [07:49] didrocks: just did as osomon appeared to be online [07:49] great :) [07:50] didrocks: there's something going on at platform-api, ../mir/mir.project* doesn't exist http://10.97.0.1:8080/view/cu2d/view/Head/view/Platform/job/cu2d-platform-head-1.1prepare-platform-api/226/console [07:51] Mirv: yeah, I changed the job so that it's starting to be green instead of yellow [07:52] Mirv: in fact, it means that there is nothing to release (see the logs before) [07:52] :) [07:52] there is force_rebuild set [07:52] but the condition "having a newest Mir" isn't met [07:52] so no need for rebuilding [07:52] good morning sil2100 [07:52] it should just be green in that case [07:52] let me relaunch, I fixed it [07:52] Good morning everyone! [07:52] didrocks: ah, that kind of dependency [07:53] hello sil2100 [07:53] Mirv: exactly, this is to avoid rebuilding platform-api and unity-system-compositor if it's not needed [07:53] Mirv: should be green now :) [07:54] it's green now. ok, just mirslave and unity tests running, all others green [07:54] sweet! [07:54] Mirv: so I see this daily-release run is ready? :) [07:55] sil2100: two runs already :) [07:55] Excellent! [07:55] Then I'll deal with the next one then [07:55] yeah, it's nice when it's releasing quickly, there is not so much ;) [07:55] sil2100: wait for unity/mirslave to finish [07:56] didrocks: there is still time, hope unity will manage! [07:56] yeah and mirslave [07:56] last ran blocked on ati :/ [07:56] (even with latest compiz) [07:59] tjaalton, still hoping to get g-c-c 3.8 in, but really not much time left. [07:59] ;/ [08:01] didrocks: that's too bad then... but at least we're no longer running an 'external application from another package' from inside of compiz, which I always thought was a bit strange [08:01] darkxst: same blocker? [08:01] sil2100: right, it's not that bad, as we don't have unity-2d anymore anyway [08:01] sil2100: I gave RAOF access this morning, he's preparing a new version of Mir/u-s-c/Xmir with intrumentation [08:02] tjaalton, yes, but there is a bunch of additional minor issues, that I can't fix since the desktop team hasnt even looked at it yet to decide what they want [08:02] I did fix all the major blockers [08:02] didrocks: \o/ would be nice to finally know what's up with mir and the ati machine [08:02] yeah ;) [08:02] Strange that no one encountered it locally though [08:06] darkxst: that's cool [08:29] Mirv, didrocks: unity testing finished \o/ [08:29] sil2100: great \o/ [08:29] ATI had a bit too many failures it seems, I even saw it was a bit slower then the others - probably some timeouts or hangups [08:29] (unity-system-compositor passed) [08:30] didrocks: \o/ [08:30] in the way, unityshell was loaded this time :) [08:30] Ok, so we're clear for the next run [08:30] sil2100: it's intel rather: http://10.97.0.1:8080/view/cu2d/view/Head/view/Unity/job/cu2d-unity-head-2.2check/328/console [08:30] sil2100: jibel stops at the first card which doesn't pass [08:30] (too many regressions for intel) [08:31] didrocks: oh, but I checked here: http://10.97.0.1:8080/job/autopilot-saucy-daily_release/956/testReport/ [08:31] sil2100: depending on what you want, if you poke upstream to get the number lower (we need that anyway, 17 is way too much) [08:31] didrocks: but right [08:31] we can force publishing [08:31] it's your pick [08:31] but in any case, ensure that you or Mirv track upstream to get the number of flacky tests down [08:31] didrocks: ok, but if I poke them, you think it's ok to force publishing? [08:32] sil2100: yeah, I think that's fine for that time [08:32] (to not having another unity rebuild for nothing) [08:32] didrocks: btw. in the end, in such a case how am I supposed to force publishing again ;) ? I mean, do I have to do it from the head job somehow? [08:32] didrocks: since I remember yesterday something with running the publish job manually was wrong or something? [08:33] (it anyway doesn't propagate properly to the head job) [08:33] I would like a head job flag such as 'do only publishing, but don't force the publication yet' [08:33] sil2100: so, run it on the head [08:33] So that I can see if the publish is yellow or not [08:33] with AUTO_PUBLICATION on [08:33] not FORCE_PUBLICATION [08:33] Oh :D [08:34] : D [08:34] didrocks: it seems you were reading my mind and prepared everything beforehand! [08:34] didrocks: with foo, yes? [08:34] sil2100: ahah, I try to prepare all cases where we need to manually unblock things ;) [08:34] sil2100: doesn't matter :p [08:36] ah, we are in that case [08:36] "the previous run already failed, can't republish automatically the stack. Report to that run to get more info." [08:36] hmm [08:36] let me try to think if that's really needed, because it was a double shield protection [08:37] sil2100: should we define for that trick to be foo + AUTO_PUBLICATION? [08:38] didrocks: you mean, that it would still run publish even if the previous run failed when it's a special case of AUTO_PUBLICATION and foo as the project to build? [08:38] sil2100: right [08:38] I doubt we need another flag for that [08:39] didrocks: fine with me, but it would be nice to document it somewhere [08:39] didrocks: quirks of jenkins daily-release ;) [08:39] sil2100: we need to have that controller out of jenkins [08:39] sil2100: normally, we should never ever have to do that btw ;) [08:41] sil2100: ok, redeployed, do you mind trying that? [08:41] didrocks: trying! [08:42] didrocks: seems like the same [08:42] didrocks: "the previous run already failed, can't republish automatically the stack. Report to that run to get more info." [08:42] interesting [08:43] and rebuild_only is set to foo… [08:43] sil2100: sorry, I'm *really* stupid [08:44] esil2100: should be better now, please try again. Btw, I added another message to tell to use "foo" to force a normal manual publication [08:45] one day, I'll learn the difference between = and != [08:45] Trying ;) [08:45] hehe, typos happen! [08:45] didrocks: it seems to be working \o/ [08:46] great ;) [08:46] sil2100: the message will now be FYI/ [08:46] + echo "ERROR: The previous run already failed, can't republish automatically the stack. Report to that run to get more info." [08:46] + echo "If you wanted to try/force a manual regular publication, you can use AUTO_PUBLICATION and set REBUILD_ONLY to foo to bypass this safeguard." [08:46] sil2100: sounds legit? ^ [08:46] we will need to redeploy all stacks to get that in production though [08:46] didrocks: sounds good indeed! [08:47] We still have like 13 minutes to the next run to start, right? [08:47] sil2100: Mirv: ZOMG it's all green! quick quick, tape a picture: http://10.97.0.1:8080/view/cu2d/view/Head/ [08:47] asac: you as well, we have prooves! :) [08:47] OHSHIT [08:47] sil2100: 1h13 [08:47] sil2100: meanwhile, maybe you can start lurking as well on the Raring/SRU side? [08:47] didrocks: ah! I think I forgot about the UTC offset ;) [08:47] (seeing if stuff are stuck in proposed) [08:48] sil2100: heh, yeah, we are +2 ;) [08:48] didrocks: ok! [08:48] that will be an interesting challenge with the UTC offset [08:48] I set the times so that every run can be looked at [08:48] so, I think we may need to move the time with UTC change, or just not caring of the delta [08:49] let's see [08:50] didrocks: nice!!!!!! [08:51] didrocks: !!! [08:51] well done [08:51] I'll take a screenshot for sure [08:51] :) [08:51] didrocks: what about phone testing ? guess thats next? [08:51] or is that already in those greens? [08:52] asac: no, it's not [08:52] right [08:52] asac: I'm still on a huge backlog, as told in the meeting, I'll need someone in the QA team to help [08:53] didrocks: do they know how otto is done etc.? [08:53] Mirv is desperatly waiting on me for Qt for instance :) [08:53] asac: I'm unsure of it [08:53] didrocks: could we try to use utah for the provisioning part? what special requirements do we have for daily-release? [08:53] use/reuse [08:54] asac: jibel transmitted the requirements to the UTAH team [08:54] which are basically: [08:54] - be able to specify a ppa [08:54] - be able to have a list of packages we filter on (like, if we install more than this list of packages, bails out and show a diff) [08:54] - have a switch to disable this previous check, for multiple runs [08:55] - have a switch to dist-upgrade from the whole ppa [08:55] - have a snapshot capability that we can transmit usptream to rerun that locally [08:55] - and have a way to ssh to the machine while it's running [08:55] - oh also: if we kill the jenkins job, the test should be aborted [08:55] and be able to run the next one [08:56] - and have the timeout working (it regressed a lot in the past) [08:56] this is in addition to have a stable runs of course [08:56] didrocks: how often do you use ssh? [08:56] asac: almost daily [08:56] when upstream need to investigate live [08:56] because they can't reproduce locally [08:57] interesting [08:57] RAOF for instance was connected this morning for Mir [08:57] didrocks: how long do we leave an instance live? [08:57] of course, when we ssh, the machine should be temporarly deprovisionning [08:57] asac: 2h [08:57] after it has failed [08:57] 2h? [08:57] ah [08:57] 2h is the timeout [08:57] if the machine is stuck [08:57] or is is a special job for "hacking"? [08:57] then, we have snapshot [08:57] and we can restore any snapshot from the past week [08:58] which will restore the same environment when you left [08:58] didrocks: so you basically say we need an lxc solution? [08:58] asac: not sure, I guess with a VM this will be possible as well [08:58] sure [08:58] but right now we dont have VM [08:58] and we dont have lxc [08:58] so not sure if your requirements are realisitic short term [08:58] maybe i am wrong about lxc [08:59] lets see how stuff is going on the emulator front [08:59] xnox: ^^ :) [08:59] asac: can we have at least the UTAH team looking at them and giving an answer? [08:59] you could safe the world [08:59] yeah ;) [08:59] we all rely on xnox! [08:59] asac: but that's what we need daily basically and from what I know, it's the gap we missed with UTAH in the early days [08:59] didrocks: no... utah team are not able to solve problems like "ouch we have no virtualization solution on our phone" [09:00] thats just unrealistic. the experts about that are elsewhere [09:00] asac: I meant for the rest, like ppa, filtering package list and so on [09:00] aborting when the jenkins job aborts [09:00] didrocks: so would a solution with just the "realisitic" things be useful? [09:00] asac: I think this will block everything [09:01] like if upstream can't debug what's wrong live… we'll be way slower to fix issues [09:01] i know [09:01] so you say we shouldn't even try to get anythng that isnt virtualized there [09:01] this is what happened with unity during the natty cycle [09:01] I think so [09:01] otoh we have the problems then in the image [09:01] which slows stuff even more down [09:01] because the distance from image to developer is even greater and the disconnect as well [09:01] wdym? [09:02] with the virtualization? [09:02] didrocks: people have problems fixing bugs that we see on real phones [09:02] saying we slow down development because we block those issues at daily-release stage [09:02] is probably not right [09:02] right now we just dont see lots of problems and hence dont care [09:02] anyway [09:03] lets wait for xnox to bring us good news [09:03] yeah, let's see [09:03] didrocks: asac: i'm at debconf this week. I will come back to above, when available. [09:04] didrocks: asac: per-se lxc doesn't provide snapshots, the emulator does copy/snapshot the virtual disks to provide a snapshot, but there is little or no cost starting a fresh emulator each time. [09:05] xnox: asac: right, we do emulate snapshot ourselves [09:05] providing a tar that people can restart [09:06] didrocks: asac: i didn't bring up unflipped yet to the point of working/booting the gui. And not sure how much flipped bring up will need, since i don't think goldfish kernel has lxc ported/enabled. [09:07] asac: I think on the phone, we won't have the snapshot at first, so that can be delayed, but at least, the same configuration for developers will help (and a way to ssh to the machines/unprovision-reprovision) === tkamppeter_ is now known as tkamppeter [09:30] sil2100: latest change redeployed everywhere [09:31] didrocks: \o/ right on time! [09:31] heh ;) [09:39] Oh! No seb128! [09:45] sil2100: not today [09:45] he will be connected at 5pm approx [09:45] ACK [09:46] Since I have a g-c-c-u question from raring [09:47] g-c-c-u is stuck in -proposed, not sure what to do exactly, as there is one bug fixed there but not fixed 'completely' - and it's arguable if we should release it like that or not [09:48] ah ok, let's wait for him maybe :) [09:59] ! [09:59] Hello seb128 [09:59] sil2100, hey, how are you? [10:00] seb128: already arrived? [10:00] didrocks, no, in Zurich [10:00] ah ok :) [10:00] seb128: quick quick, 2 minutes before next run: http://10.97.0.1:8080/view/cu2d/view/Head/ [10:01] didrocks, something went wrong with the red color [10:01] it went missing [10:01] ? [10:01] seb128: right, we changed jenkins' assets :) [10:02] ;-) [10:02] nice one indeed [10:02] did you take a screenshot to have a proof it happened? ;-) [10:02] apparently, we are multiple to have taken some :) [10:02] seb128: how is the travel btw? everything on time? [10:03] nice that you have Wifi :) [10:03] didrocks, yeah, everything is just fine, first flight was around 40min and second one is around 1h [10:03] Zurich airport is nice for that [10:04] they have one hour free wifi available from pretty much anywhere in the airport [10:04] great ;) [10:05] Awesome :) [10:21] didrocks: hm, strangeness! Webapps is red because of the check job, which didn't even run [10:21] ERROR: Build aborted. No projects to trigger. Check your configuration! [10:21] http://10.97.0.1:8080/view/cu2d/view/Head/view/WebApps/job/cu2d-webapp-head-2.2check/58/console [10:21] sil2100: right, I'm looking at that just now [10:21] sil2100: I wonder why when redeploying, commenting the check wasn't enough [10:21] sil2100: you know… as we disabled the check for it [10:21] it shouldn't even have been ran [10:21] (I only wanted to comment the minimal part) [10:22] hmm [10:22] sil2100: ok, commenting everything then [10:22] (redeploying and rerunning) [10:23] didrocks: but this will mean the need for redeployment of everything again? Watch out for other projects that might be running! [10:23] sil2100: no no, only webapps is in that case [10:23] ok, boarding time, back online in some hours [10:23] if 'extracheck' in stack and stack['extracheck']: [10:24] seb128: safe travel [10:24] didrocks, thanks [10:24] sil2100: any idea why even with extracheck: False, it's trying to get it? [10:24] oh maybe yaml want a space before # [10:24] it's extracheck: False#autopilot-saucy-daily_release [10:25] didrocks: could be, I never tried doing that without a whitespace before # [10:26] sil2100: yeah, that was it :) [10:26] * didrocks reruns webapp [10:26] sil2100: ah, the -check job is off the hook now :) [10:27] sil2100: so, I just delete the -check job for now, ok? [10:27] btw. why was the check job for webapps disabled? [10:27] sil2100: so that the "view" can be green [10:27] Ok [10:28] sil2100: because nobody is fixing unity_qml_webapps [10:28] sil2100: so it's disabled for dailies [10:28] didrocks: ;/ [10:28] we gave them a week [10:36] Good morning :) [10:37] hey czajkowski [10:38] heya [10:38] so running saucy and loving it however what ever updates I did last night is leading to much brokenness this morning., :( [10:38] https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1205896 [10:38] czajkowski: Error: launchpad bug 1205896 not found [10:38] https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/1211718 [10:38] czajkowski: Error: launchpad bug 1211718 not found [10:38] all happen on start up [10:38] :/ [10:39] czajkowski: I would blame new glib, seeing the stacktrace. Mind pinging seb128 when he's back? [10:39] desrt: or maybe you can have a look dude? ^ [10:40] (the second one is not retraced yet) [10:40] * didrocks goes for a run, see you later [10:41] didrocks: cheers [10:53] seb128 is for once not here :( === dpm_ is now known as dpm [11:07] didrocks: there seems to be an extra package missing in platform-api [11:07] didrocks: let me check that and fix it === MacSlow is now known as MacSlow|lunch [11:20] didrocks: i get 404s for those pages? [11:23] desrt: let me add you to them [11:23] they're private bugs [11:24] desrt: what is your LP id ? [11:25] didrocks: once you're back: https://code.launchpad.net/~sil2100/cupstream2distro-config/add_hardware-api_to_platform/+merge/179900 [11:25] I jump out for lunch and dentist [11:26] czajkowski: desrt [11:27] done :) [11:50] sil2100: approved [11:56] sil2100: rerun and approving the packaging changes I already approved :) === MacSlow|lunch is now known as MacSlow [12:16] ;) [12:16] didrocks: ok [12:19] hmm, bug 1189850 says it's fixed but I'm still seeing lots of corruption on Intel on saucy [12:19] Launchpad bug 1189850 in xserver-xorg-video-intel (Ubuntu) "(Needs a 3.10.3 kernel) saucy/raring has frequent image corruption (intel, sna)" [High,Fix released] https://launchpad.net/bugs/1189850 [12:20] ahh, "needs a 3.10.3 kernel"? [12:29] czajkowski: these two traces don't look particularly related [12:30] #25 0x00007f574a3e2d9b in dconf_settings_backend_write (backend=0x164c9d0, key=0x200c5d0 "/org/gnome/eog/view/background-color", value=0x1c13690, origin_tag=0x0) at dconfsettingsbackend.c:79 [12:30] uh [12:32] ya... that's a bug [12:33] EogScrollView is hooking up bidirectional gsettings bindings to _itself_ during _construction_ [12:38] ah well at least it makes sense to you :) [12:38] although i'm sure that this is definitely wrong, i wonder if there is something else that is wrong as well [12:39] simple fix: changing G_SETTINGS_BIND_DEFAULT, to G_SETTINGS_BIND_GET on line 2561 of eog-scrolled-view.c [12:39] but there may be another bug hiding out here [12:41] I have removed the binary package ghostscript-cups and have moved the contents into cups-filters, is it OK if cups-filters has breaks/conflicts/replaces: ghostscript-cups? Or do I need a ghostscript-cups transitional package (provided by which source package and what should it depend on?). How can I make an update uninstall the current ghostscript-cups when cups-filters 1.0.36 gets installed? [12:41] any intel users seeing desktop lockups as per bug 1211754 ? [12:41] Launchpad bug 1211754 in unity (Ubuntu) "Desktop freezes for some seconds then continues" [Undecided,New] https://launchpad.net/bugs/1211754 === mdeslaur_ is now known as mdeslaur [12:45]