=== _salem is now known as salem_ === salem_ is now known as _salem === jhodapp is now known as jhodapp|afk [10:01] hi guys [10:02] can someone help me with compiz please? [10:40] dednick: hey, the unlock SIM entry is gone again [10:42] mzanetti: can you run the indicators-client and get a copy of the network indicator info? [10:42] dednick: how? [10:43] dednick: do I need to install the indicators-client? [10:43] dednick: 'cause this is a read only dogfooding phone [10:43] mzanetti: yeah [10:44] but I guess I can make it writable to debug this and then flash it again [10:44] and then. in the indicators-client, click on the network indicator, and de-select enable visual representation [10:44] dednick: ok. will take a bit as I have an appointment soon and when I come back a bunch of meetings. but I'll try to get it debugged today [10:44] mzanetti: ok. thanks [11:08] greyback: check out the last comments on that bug... I'm not sure what to do with it tbh [11:10] greyback: basically what it says is that we shouldn't ever use stopApplication() but just close the app's window and hope that the app is implemented in a way that it calls quit() on its own when the window closes === MacSlow is now known as MacSlow|lunch [11:11] mzanetti: I'm not sure if mir let's shell close a surface right now [11:11] lets [11:17] greyback: but isn't that what's already happening? [11:20] mzanetti: we start/stop apps, but we don't close their surfaces on them, just hide them [11:23] hmm.. ok [11:45] tsdgeos: hi! Saviq not around today? [11:45] sil2100: he's travelling back home [11:45] sil2100: maybe in the late afternoon/eveining [11:46] ah, thanks [11:46] tsdgeos: anyway, since you might know some info about this one - did you have any time to look into https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1256360 ? [11:46] Ubuntu bug 1256360 in Mir "unity8 crashed with SIGSEGV in glDeleteTextures() from mir::scene::GLPixelBuffer::~GLPixelBuffer() from mir::scene::ThreadedSnapshotStrategy::~ThreadedSnapshotStrategy()" [High,New] [11:46] tsdgeos: I have been told that management thinks about making that a promotion blocker ;/ [11:48] sil2100: that's only on shutdown of unity8 [11:48] least important thing ever imho [11:48] that's all i can say :D [11:48] tsdgeos: yeah, well, I'm not management so ;p [11:48] i can show you much more worse things i'd like to consider a blocker [11:48] tsdgeos: I also thought about it as low prio, but it seems there are people that want this gone [11:48] sil2100: i did not look at it at all, you'll have to get Saviq [11:49] k, thanks ;) [11:49] i mean [11:49] i did look at it but not past the "ok it's on crash not important" [11:49] phase === alan_g is now known as alan_g|lunch === davidcalle_ is now known as davidcalle === MacSlow|lunch is now known as MacSlow === alan_g|lunch is now known as alan_g [12:52] Всем привет. Кто может помочь? Панель Unity (ширина) не учитывается, получается ширина окон больше на ширину панели, края окон срезаются. [12:53] Oxid: please try #ubuntu-ru there are not that many russian speaking people here. [12:53] Oxid, this is mostly a development related and english speaking channel [12:53] Oxid: or try in english, if you can =) [12:53] ok :) [12:58] Hello. Who can help? Panel Unity (width) is not taken into account, it turns out windows more width to the width of the panel, the edges beveled windows. [13:02] Cimi: https://code.launchpad.net/~aacid/unity8/carouselLastItemClick/+merge/214230 [13:03] or mzanetti: https://code.launchpad.net/~aacid/unity8/carouselLastItemClick/+merge/214230 [13:05] tsdgeos, why no stepanimation at end? [13:05] I'm not convinced [13:05] Cimi: ? [13:05] i do have a stepanimation at end [13:05] you didn't [13:05] so convince yourself [13:06] and then go review the code again [13:06] and even may use tryCarousel [13:06] before commenting on it :) [13:06] ahahah [13:06] tsdgeos, so why you added it? [13:06] because [13:07] i'm pretty sure the only reason it was there it was because the last x calculation was buggy [13:07] as it was (since that's the other thing i fixed) [13:07] and that was only there to hide it [13:08] note the real fix is inside the getXFromContinuousIndex function [13:09] and anyway i'm not claiming i understand the code, i just claim it fixes stuff ;) [13:10] Cimi: you're free to provide an alternate fix :) === dandrader is now known as dandrader|afk [13:24] tsdgeos, found the original code [13:24] hold on === _salem is now known as salem_ [13:27] tsdgeos, actually, this part is missing [13:27] it comes with a big commit [13:27] tsdgeos, I'd not approve the branch until I realise what's going omn [13:28] Cimi: that's why i asked you to review [13:28] tsdgeos, so my idea [13:28] tsdgeos, is that you can scroll without reaching the end [13:28] imagine you scroll 98% [13:29] tsdgeos, in this case you _need? the step animation [13:29] you do [13:29] ok cool [13:29] so when you're at the end [13:29] do you still need it? [13:29] you do [13:29] nope [13:29] you do because your code checks for < 1 pixel [13:30] and the list with scale and stuff [13:30] it's not that accurate [13:30] tsdgeos, I'll review the branch properly [13:30] so you basically "reset" the position [13:30] with manual testing and such [13:30] Cimi: thanks for doing what i asked you to do, that is really helpful :) [13:33] mterry: mornings [13:33] tsdgeos, hello! [13:34] mterry: deja-dup killed my machine this morning on boot :'( [13:34] tsdgeos, killed your machine? [13:34] ate all my RAM [13:34] took me 30 min to kill it and recover from so much swapping :D [13:35] Huh.... [13:35] tsdgeos, I've had a report on Fedora of that a while ago, but no one could reproduce [13:37] mterry: i can't either [13:37] rebooted again just to try [13:37] and it all went fine [13:39] tsdgeos, sorry bro :-/ [13:39] mterry: no worries, i know it's close to imposible to debug [13:39] mterry: do you think there's anything i can do to help in the future in case it happens again? [13:40] ls [13:40] wops :D [13:40] tsdgeos, uh... I guess get a backtrace of what it thinks it's doing. But that's hard if your system is going kaput [13:40] tsdgeos, do you know if this was the deja-dup-monitor exe or the deja-dup one? [13:41] i remember a monitor in the top/iotop output [13:41] so probably the first [13:44] Saviq: you around yet? [13:44] mzanetti: he was travelling this morning, not sure he had time to get home already [13:55] greyback: just realized that the bug is only invalid for the settings app. [13:56] greyback: I've added the checklist in case we want to land this for now [14:01] mzanetti: ok. I'll have to leave it to you to find out if that solution is acceptable to people [14:02] greyback: ok. but if it isn't I'll have to leave the other fix to you :P [14:02] mzanetti: ok [14:21] Saviq, ping bug 1302213 [14:21] bug 1302213 in Unity 8 "API to bring down the session" [Undecided,New] https://launchpad.net/bugs/1302213 === dandrader|afk is now known as dandrader === alan_g is now known as alan_g|tea === alan_g|tea is now known as alan_g [14:39] didrocks, need your help with the sobump [14:39] mhr3: sure? [14:39] didrocks, sure :) [14:40] ahah, was more "sure, what's up?" [14:40] but if you are really really sure… :p [14:40] didrocks, so problem we just realized we have - the libunity-scopesX pkg contains binaries for scoperunner and scoperegistry [14:40] and those link against the lib [14:40] but they're not versioned in anyway, so you can't really install both libunity-scopes0 and 1 [14:41] right [14:41] do you want to? [14:41] do i just add breaks, replaces, conflicts to 1, to get rid of 0? [14:41] exactly [14:41] conflict/replaces/provides [14:41] rather [14:41] provides? [14:41] to help apt to understand the transition [14:41] yeah [14:41] no breaks? [14:41] no [14:42] how to phrase that [14:42] and it would provide 0? [14:42] let's say "breaks is temporary" [14:42] it's a transiant state [14:42] but libunity0 would be reinstalled at a later point [14:42] conflict is definitive [14:42] yeah, provides is an issue [14:42] don't set it [14:42] however, apt may have some troubles upgrading [14:42] so just conflicts + replaces? [14:43] how many packages have a dependency on libunity-scopes0? [14:43] directly, zero [14:43] it's via libunity-scopes-dev [14:43] and what's dep on libunity-scopes-dev? [14:43] not a whole lot I guess [14:43] 4 pkgs [14:44] hum [14:44] mzanetti, now [14:44] $ reverse-depends libunity-scopes0 [14:44] * unity-plugin-scopes [14:44] * unity-scope-click [amd64 arm64 armhf i386] [14:44] Saviq: wb [14:44] * unity-scope-mediascanner2 [14:44] * unity-scope-scopes [14:44] that should be enough [14:44] to force the transition [14:44] so yeah, only conflicts + replaces [14:44] ok [14:45] Saviq: on the last 2 comments in here: https://bugs.launchpad.net/ubuntu/+source/unity-mir/+bug/1273781 [14:45] Ubuntu bug 1273781 in unity-mir (Ubuntu) "If you open the accounts page in the settings app and close it you can't reopen it" [Undecided,In progress] [14:45] Saviq: does that mean we don't want this fix? https://code.launchpad.net/~mzanetti/unity-mir/quit-manually-started-procs/+merge/214013 [14:45] didrocks, and the ultimate solution is to start versioning everything, so that 0 and 1 could be installed in parallel, right? [14:45] or should we do this for now until Mir properly closes the window [14:46] didrocks, meaning the "proper" solution [14:46] mardy, can we SIGTERM the signon-ui for now? ↑↑ [14:47] mhr3: there is no chance for a service using on libunity version to be compatible with the other one? [14:47] mhr3: like, dbus protocol being compatible? (if any) [14:47] mzanetti, q:, though, are we SIGSTOP'ing non-upstart apps? [14:47] Saviq: yep [14:48] Saviq: we get the PID from mir and use that one to SIG* === alan_g is now known as alan_g|tea [14:48] Saviq: except for closing down we use upstart's PID which isn't set in this case [14:48] didrocks, scopes by 3rd parties will be built using any released soversion, so we will need to provide compability [14:48] mzanetti, so SIGTERM isn't enough [14:48] mzanetti, we need SIGCONT, too [14:48] Saviq: I'd rather not... though in practice I don't think that this will cause big problems [14:48] Saviq: I tried. it is enough [14:49] mhr3: part of the issue is that now britney is only offering you to have one version at any time [14:49] mzanetti, when a process is SIGSTOP, it can't do anything in reaction to a SIGTERM [14:49] mhr3: or you need to fork the source [14:49] didrocks, who's britney? :) [14:49] Saviq: also we don't SIGCONT other apps before asking upstart to close them [14:49] spears? [14:49] Saviq, mzanetti: I'd vote for unconfined processes not to be stopped, if my vote has any importance :-) [14:49] mhr3: she doesn't sing though :p it's what is handling proposed -> release pocket migration [14:49] mzanetti, that's different, upstart SIGTERMs and SIGKILLs after 5s [14:50] mardy, that'd be an interim solution [14:50] didrocks, we'll need to do something about it [14:50] didrocks, but it doesn't have to be done now [14:50] Saviq: why interim? Can't it be like that forever? [14:50] didrocks, haven't reached 1.0 yet :) [14:50] mardy, I mean SIGTERM would be interim [14:51] mhr3: yeah, I think we'll have to fork the source or multiple builds from same source… [14:51] mardy, but anyway, shell has no idea of confined or unconfined [14:51] Saviq: ah, OK [14:51] didrocks, i guess so :/ [14:51] mardy: this just handles the case that upstart say "huh, I can't stop that app" [14:52] Saviq, mzanetti: OK [14:52] mardy: in this case we send it a SIGTERM (for now). as your suggestion (which I think we all agree with) requires more work in the lower layers first [14:52] mardy, long-term we'll definitely ask the app to quit gracefully, and probably kill it after a timeout [14:52] mardy, might be different for trusted helpers, though [14:52] Saviq: what about your idea to send the window closed event to all apps (even those started by upstart), before killing them? That sounded very reasonable to me [14:52] mzanetti: OK, that should be fine [14:53] mardy, yeah, that'd be the plan [14:53] mardy, and term/kill after a timeout [14:53] mardy, but again, trusted helpers will probably be exempt from that [14:53] mzanetti, but really, you can't TERM an STOP'ed app [14:54] mzanetti, so either we're not STOPing, which would be a bug in itself [14:54] mzanetti, or your testing failed :) [14:54] * Saviq goes for foo [14:54] I tend to agree with you from a theoretical POV, but my observations have been different [14:54] d [14:54] Saviq: wait [14:55] will you joing the meetin now? [14:55] mzanetti, yeah, I mean food like in the kitchen [14:55] wait! The food is poisoned! [14:55] :D [14:55] ssshhht === alan_g|tea is now known as alan_g [14:58] mzanetti, Saviq, so this was an issue for the QA folks, in that they want to stop an app via UAL that Unity has SIGSTOP'd. [14:58] tedg, yeah, we should SIGCONT them before stopping via UAL [14:58] tedg, ah [14:58] I'm curious whether we shouldn't be SIGCONT'ing them [14:58] you mean completely outside [14:59] Yeah, via the test script [14:59] tedg, yeah, they need to SIGCONT them indeed [14:59] tedg, upstart will SIGKILL them, though, so they will exit after 5s [14:59] Yeah, and they're seeing that, but they'd like to be able be a little better. [14:59] Is there a way to ask Unity to close an app? [15:00] Like that QA could use. [15:00] I feel a little weird just sending SIGCONT blindly. [15:01] Saviq: right... the seems we're failing to SIGSTOP those not started by upstart [15:01] mzanetti, yeah, I thought so, which might actually be OK === jono is now known as Guest82898 [15:04] mzanetti, Saviq, Are you not starting unconfined apps using upstart? [15:04] Well UAL. [15:05] tedg: there are some exceptions. if you launch the online-accunts-ui from the settings app for example [15:05] tedg: or autopilot runs most of them by system call still [15:05] tedg: or qtcreator does currently [15:05] That's just because of the trusted session stuff not being complete? [15:05] Those all go away with the sidestage stuff landing, no? [15:06] i.e. no --desktop_file_hint= [15:16] Saviq: just letting you know I fixed the embarrassing build failure in the libusermetrics branch [15:16] pete-woods, oh ok, didn't know there was one :) [15:16] pete-woods, will kick the silo again soon [15:16] yeah, symbols fail [15:17] teach me to push without running bzr bd === bschaefer_ is now known as bschaefer === gatox is now known as gatox_lunch [15:47] Saviq: so i asked camako & AlbertA to jump on the "unity8 crashes" during AP that someone debugged to be a mir prob... [15:47] can someone provide some color commentary ? [15:48] e.g. it lead back to an old bug we thot was fixed, so i'm thinking diff root cause [15:48] "They're debugging this like a NASCAR race on the last turn! Crashes Everywhere!" [15:48] just looking for a breadcrumb trail [15:48] * tedg does color [15:48] thanks tedg :) :/ [15:49] kgunn, if you can make my phone update faster I'll have less time for IRC :-) [15:51] lol [15:52] * davmor2 slips a 4g chip into tedg 's phone [15:53] AlbertA: camako ...so i think maybe the more appropriate bug is this one [15:53] https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1302550 [15:53] Ubuntu bug 1256360 in unity8 (Ubuntu) "duplicate for #1302550 unity8 crashed with SIGSEGV in glDeleteTextures() from mir::scene::GLPixelBuffer::~GLPixelBuffer() from mir::scene::ThreadedSnapshotStrategy::~ThreadedSnapshotStrategy()" [Medium,Confirmed] [15:53] ....which someone dup'd, and probably too quickly imho [15:56] kgunn: ahh ok, so this is the more recent occurrence then: [15:56] kgunn: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1302550 [15:57] Ubuntu bug 1256360 in unity8 (Ubuntu) "duplicate for #1302550 unity8 crashed with SIGSEGV in glDeleteTextures() from mir::scene::GLPixelBuffer::~GLPixelBuffer() from mir::scene::ThreadedSnapshotStrategy::~ThreadedSnapshotStrategy()" [Medium,Confirmed] [15:57] yes [15:57] I see [15:57] ok I'll take a look === gatox_lunch is now known as gatox [16:27] tedg, yes, that will go away ultimately [16:27] kgunn, the glDeleteTextures one? [16:27] Saviq, Will or has? I figured it was already gone :-) [16:28] tedg, will, has not, yet [16:28] kgunn, it happens on unity8 exit sometimes [16:28] Saviq, K [16:28] Saviq, Thoughts on the session shutdown? [16:29] kgunn, so if you just go "while true; do restart unity8; done", you [16:29] 'll get it after a few runs [16:29] tedg, I think maybe we should just mimic the gnome-session api? [16:30] Saviq, It's pretty big as it deals with all the session management stuff. The command we're interested in is just "LogOut()" [16:31] tedg, sure, we can start with that, and grow it as we go [16:31] Saviq, So really you are, if you want to call it LogOut I'm fine with that :-) [16:31] tedg, think we should put this on the same interface name, or is that a bad thing to do? [16:31] erm [16:31] object path I meant [16:32] Saviq, I think it's bad for two reasons, one some but not all is kinda confusing, and two gnome-session is going away upstream. They probably won't keep the path either. [16:32] tedg, there should be some fdo spec ;) [16:33] There's some work on that. [16:33] oh, so maybe we could try and go towards that [16:33] Unfortunately it's mixing application management and session management. [16:34] They're focused on the inhibition problem, which we want to go through the Application Lifecycle stuff. [16:35] AlbertA: camako ....scrollback saviq says just go "while true; do restart unity8; done" you'll hit it after a few runs... [16:35] its an issue because unity8 is exited for our AP testing [16:35] camako: AP == autopilot :) [16:37] kgunn, camako, AlbertA, obvious issue for debugging is that it's running under upstart, you might want to run it under gdb, so `stop unity8`, export MIR_ things (you can check which in initctl get-env --global | grep MIR), and then loop it under gdb [16:38] SIGILL on startup is expected, so you might go "gdb -ex run -ex continue unity8" or so [16:39] from the bug descriptiong, it's using the app screenshot code, so just starting/stopping unity8 probably won't reproduce it. You need an app to be running [16:45] greyback, yeah, that description might be wrong [16:45] greyback, i.e. I initially thought that [16:45] greyback, but not sure any more [16:45] Saviq: ok [16:45] I think I got it without apps, too [16:53] Saviq, So, I need a yes/no on adding a logout function. I'll take anything as the path/interface name that you'd like :-) [16:53] * tedg reloaded the bug [16:53] Saviq, Thanks! [17:00] tedg, cheers, hope to make it happen next week === alan_g is now known as alan_g|EOD [17:27] kgunn: I just noticed this branch hasn't landed for a while in papi: [17:27] lp:~andreas-pokorny/platform-api/fix-cross-compiling [17:28] kgunn: who needs to review it? [17:29] anpok:^ [18:29] mzanetti, hi [18:35] mzanetti, one for you: bug #1302761 [18:35] bug 1302761 in unity8 (Ubuntu) "Wrong icon when dragging items in the launcher" [Undecided,New] https://launchpad.net/bugs/1302761 [19:12] AlbertA: i got sidetracked...but on that papi MP...i'll try to land [19:27] kgunn: thanks [19:45] Saviq: thanks I used list-env [19:45] Saviq: however you do require something exercising the snapshot [19:45] Saviq: otherwise there's no texture to delete and no issue [20:00] kgunn: camako: I don't have a reproduction case yet, but I think this is simply a case [20:00] kgunn: camako: glDeleteTextures is called from a thread other than the one that created the texture [20:01] kgunn: camako: we should just do make current before deleting the texture as that object uniquely owns its gl context [20:02] AlbertA: sounds good to me [20:02] AlbertA, I wasn't sure it was limited to a screenshot case, but does make sense [20:02] AlbertA: camako ...so, i suppose we'll wanna hot fix mir/trusty as well as devel [20:04] AlbertA: we shld be careful that his doesn't get called too often... Makecurrent is expensive... [20:04] kgunn: so mir 18 has been promoted already? [20:04] AlbertA: nope... [20:04] camako: we are already calling make current all the time :) [20:04] AlbertA: Calling thread doesn't have a way of notifying the rendering thread, so it can call this? [20:05] camako: it's in the destructor though so it will be whatever that thread is [20:05] in fact i was just wondering if i should grab the 018 tag version of devel...or go for the top of the tree ? [20:05] kgunn: I wondered about tagging minor version in devel [20:06] kgunn: then grabbin that...but don't kow if duflu would agree [20:06] _exactly_ [20:06] i suppose 0.1.8 tag is safer...cause i know he tested it [20:06] camako: I suppose though we could shift the texture deletion to the stop call in the functor [20:07] camako: but then you have to touch the Pixel buffer interface which assumes no gl [20:08] camako: the GLPixelBuffer has no idea from what thread is being called [20:09] Probably not a good place then... [20:09] camako: it any case, it's the destructor, which will only be called when the server is shutdown - so not often [20:10] In my mind, all threads, should have a way of talking to the render thread when they want gl work done... [20:10] probably more concerning that you say we're calling makecurrent "all the time" already [20:10] But ok.. we'll get there I guess [20:10] kgunn: make current should only be expensive the first time I thought [20:11] kgunn: assuming you don't change thread contexts [20:12] right, context switch is a buzz kill [20:12] camako: but in this case this is special work, it's not exactly rendering or compositing, it's snapshotting a client surface independently of compositing [20:13] So glReadPixels? [20:13] camako: that's the current implementation yeah [20:14] Hmm.. Why is it doing glDeleteTextures then? [20:14] camako: it's attaching the client surface, rendering to an fbo then glReadPixels [20:15] camako: attaching the client surface to a texture [20:15] I see [20:16] camako: I don't have the history context on this [20:17] * AlbertA adds todo item to provide a platform specific implementation that just mmaps perhaps [20:17] Calling makecurrent in this case is ok... But if there are all these threads hitting gl (and hence doing makecurrent) we shld pbably fix it in time [20:18] camako: well a gl context is created solely for the snapshoting, so it should be fine [20:18] camako: it should not perturb the compositor's gl context [20:26] camako: alf would be the one to quiz in the snapshot case [20:27] ok === salem_ is now known as _salem === jhodapp is now known as jhodapp|afk [23:04] kgunn: camako: https://code.launchpad.net/~albaguirre/mir/fix-1256360/+merge/214355 [23:06] kgunn: camako: I didn't get to repro the issue though - also I would think this would crash all the time...strange that reports don't say that [23:06] AlbertA: that's curious [23:07] AlbertA: I'd think that too