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