[09:06] <tsdgeos> cimi: greyback: so i guess we have to create a trunk for vivid-overlay and a trunk for wily for unity8 given how the stack below us is splitting into the same, no?
[09:07] <tsdgeos> cimi: greyback: unfortunately we need an answer "now" since otherwise pstolowski can't land stuff
[09:07] <greyback> tsdgeos: qtmir hasn't changed yet, if that's the part of the stack you're referring to
[09:07] <cimi> :/
[09:07] <tsdgeos> greyback: no, i mean all the unity-* stuff
[09:08] <cimi> saviq and mzanetti wanted to avoid that
[09:08] <pstolowski> greyback, no, just scopes stuff and plugin
[09:08] <pstolowski> cimi, we all wanted to, but i'm not sure how it is possible
[09:09] <greyback> pstolowski: the code will be the same, it's just the ABI of the binaries will be different, yeah?
[09:09] <pstolowski> cimi, here is what i get when trying to land just vivid overlay https://requests.ci-train.ubuntu.com/static/dashboard.html#?q=ubuntu%2Flanding-005
[09:09] <greyback> but the binary lib names will need to be different
[09:09] <pstolowski> greyback, yes, and it will affect deb packaging (debian/control)
[09:10] <greyback> pstolowski: why?
[09:11] <pstolowski> greyback, package names need to reflect that change afaik
[09:12] <greyback> pstolowski: if that's the case, then the whole stack will have to split. We're going to version the ABI in the package name? I would have expected the version string to be more relevant there
[09:13] <greyback> I'm beginning to to think the way of dealing with upstream code might work - 1 upstream branch, branched for each release. then as many packaging branches as we need to deal with ABI stuff
[09:15] <pstolowski> greyback, isn't it essentially the same as what we get with 2 trunks?
[09:15] <pstolowski> greyback, ah, ok got you
[09:15] <greyback> pstolowski: I don't like the phrase "2 trunks" :)
[09:17] <pstolowski> greyback, i know, that's a synonym of pain
[09:17] <pstolowski> greyback, in any case... we need a solution fast, ota is really close :/
[09:22] <tsdgeos> so
[09:22] <tsdgeos> do we go that way? or anyone wants to call on the phone michael or saviq and annoy them with this?
[09:22] <greyback> pstolowski: so I believe you can fix your build with https://code.launchpad.net/~gerboland/unity8/changelog-update-gcc5/+merge/266861
[09:23] <greyback> tsdgeos: I think we should just focus on landing for vivid+overlay, until all this mess is understood
[09:24] <tsdgeos> greyback: so you want lp:unity8 to be basically vivid-overlay targettd instead of wily?
[09:24] <greyback> that goes against the "land in devel first" thing though, so need to check with CI folk it's acceptable
[09:24] <pstolowski> greyback, we want to land vivid only atm
[09:25] <greyback> ok
[09:25] <greyback> tsdgeos: I think that's the route of least difficulty for now
[09:25] <tsdgeos> i'm fine with that
[09:25] <tsdgeos> but pstolowski says debian stuff complains about version numbers being smaller
[09:25] <tsdgeos> since if we do a vivid overlay landing only it creates 15.04 vs 15.10 or something
[09:26] <tsdgeos> greyback: does the branch you pointed help with that?
[09:26] <pstolowski> it'll still complain about 15.10 there i think
[09:27] <greyback> pstolowski: I used that in my silo 19, and it kept the train quiet
[09:27] <greyback> reason is that there's the added changelog entry in the release branch: https://code.launchpad.net/~ubuntu-branches/ubuntu/wily/unity8/wily
[09:27] <pstolowski> hmm
[09:28] <pstolowski> greyback, but if it works, this will update changelog with 'vivid' entry, in trunk. that's going to create problems, no?
[09:28] <greyback> I think if we sync that back to trunk, we should be ok. That's what my branch above does
[09:29] <greyback> pstolowski: frankly, I don't care about wily that much right now
[09:29] <pstolowski> ah, ok
[09:29] <greyback> we're landing something newer anyway, so the old version isn't so useful then
[09:30] <greyback> pstolowski: can you try adding that branch to your silo, and see if the train is happy?
[09:30] <pstolowski> greyback, ok
[09:30] <greyback> pstolowski: thanks
[09:31] <pstolowski> greyback, i presume the other silo we have which has this branch https://code.launchpad.net/~aacid/unity8/dash_activation_no_special_casing/+merge/264024 doesn't need it, because tsdgeos bumped unity8 version?
[09:32] <greyback> pstolowski: it might, as it appears bzr compares the version strings before merging
[09:33] <greyback> pstolowski: but if one lands, then this trouble should go away
[09:33] <tsdgeos> yeah let's go that way for now
[09:33] <tsdgeos> and see how to "fix it properly" later
[09:33] <tsdgeos> i guess
[09:34] <greyback> yeah. It'll have our trunk tied to vivid+overlay. We can probably do a sync release to wily if the underlying packaging is unchanged. But if it is changed, we've work to do
[09:37] <pstolowski> allright
[09:38] <cimi> greyback, tsdgeos we can do like uitk they have staging
[09:38] <tsdgeos> cimi: that doesn't help in this regard
[09:39] <tsdgeos> the problem we have is that we'll eventually need two branches because the dependencie names are going to change
[09:39] <tsdgeos> or that's what i understood
[09:41] <greyback> tsdgeos: what i do know for sure is, since gcc5 changes ABI, the library so version should be different between wily (gcc5) & vivid (gcc4.9)
[09:42] <greyback> I am still not clear on why that demands a different package name though, I need to think more perhaps
[09:43] <tsdgeos> greyback: the thing is, since we don't maitain soversion
[09:43] <tsdgeos> we need different package names
[09:43] <tsdgeos> or bump the one in wily by 100
[09:44] <tsdgeos> so that if we need to break the soversion again in vivid we don't end up on one that we used already for wily
[09:44] <pstolowski> greyback, i think just the version number doesn't prevent stuff from breaking, i think we need libfoo3 to become libfoo4 etc
[09:44] <tsdgeos> am i making sense?
[09:44] <greyback> pstolowski: yeah I think you're right
[09:44] <greyback> tsdgeos: yep
[09:51] <greyback> I'd most like lp:unity8 to be development trunk. We branch off that for each wily release. Then we cherry-pick from those branches for vivid+overlay, merging a vivid branch to downgrade dependencies
[09:57] <tsdgeos> greyback: so 3 branches in maintaince at a time?
[09:57] <tsdgeos> at least
[09:57] <tsdgeos> "development", "unstable release" and "vivid+overlay"
[10:00] <greyback> tsdgeos: effectively. With devel having the least maintenance burden naturally
[10:00] <tsdgeos> right
[10:12] <pstolowski> greyback, still fails https://requests.ci-train.ubuntu.com/static/dashboard.html#?q=ubuntu%2Flanding-005
[10:13] <pstolowski> greyback, the problem is with 15.04... vs 15.10.. version string
[10:14] <pstolowski> greyback, so i solved similar issue for my branches by manually changing the topmost changelog entry to say 15.04, vivid in my 15.04-trunks
[10:19] <greyback> pstolowski: hmmm, I dislike having to do that tho
[10:20] <pstolowski> greyback, the only 'workaround' is to bump the real package version number, but that hides the problem
[10:22] <pstolowski> greyback, or maybe not if you don't care about wily and the fact, that landing with vivid changelog entry in trunk is ok for now... i don't know tbh
[10:23] <greyback> pstolowski: bumping the version number is ok IMO
[10:23] <greyback> we shouldn't have this problem again any time soon
[10:23] <pstolowski> greyback, ok.. as i mentioned earlier we do this in silo 27 already, bumping unity8 to 8.11
[10:23] <greyback> pstolowski: yeah, I'm ok with that
[10:24] <greyback> go for it
[10:24] <pstolowski> greyback, ok, in that case your gcc5 branch my not be needed if we rebuild and land our two silos in correct order
[10:25] <greyback> pstolowski: yeah, I'll drop it since you'll have everything fixed for me :)
[10:25]  * pstolowski wishes he can focus on real coding
[10:44] <pstolowski> sil2100, hey, i've just discussed with greyback and tsdgeos above about how to land ota features in vivid overlay only for now in unity8; they will keep one trunk for the time being
[10:45] <greyback> we will work out a more comprehensive landing strategy,  but for now we want to land stuff for vivid+overlay
[10:48] <sil2100> greyback, pstolowski: is unity8 still able to dual-land?
[10:49] <greyback> sil2100: we don't think so, as it depends on so many libraries which presumably will have to change their package names to reflect the ABI change
[10:49] <tsdgeos> damnit i cant' get untiy8 to crash on the desktop anymore as it was crashing 15 min ago
[10:49]  * tsdgeos puzzled
[10:50] <pstolowski> sil2100, yes, as greyback says. we have changes in shell plugin and unity-api which need changing for gcc5 symbols changes (+ packaging changes)
[10:50] <pstolowski> sil2100, and this goes further down to mediascanner lib
[10:51] <pstolowski> sil2100, i
[10:52] <pstolowski> sil2100, i've separate trunks for 15.04 for these projects
[10:54] <sil2100> hmmm
[12:14] <dandrader> greyback_, do you know where's the bug we have about supporting apps preferred orientation?
[12:15] <dandrader> greyback_, ie, an app telling us the orientation it would like to be in at runtime
[12:15] <dandrader> greyback_, I recall we had a bug about it but could not find it
[12:17] <greyback_> dandrader: I think this is all we've got https://bugs.launchpad.net/qtmir/+bug/1379777
[12:17] <greyback_> which links to https://bugs.launchpad.net/mir/+bug/1382209
[12:17] <greyback_> which shows the mir work is done at least
[12:18] <dandrader> hmmm
[12:18] <dandrader> I'm asking this because of the last comment in https://bugs.launchpad.net/qtmir/+bug/1379777
[12:19] <dandrader> greyback_, would like to point that person to the "set runtime preferred orientation" bug
[12:19] <dandrader> greyback_, so maybe we can use https://bugs.launchpad.net/mir/+bug/1382209 for it
[12:19] <greyback_> dandrader: be nicer, explain how he can use the flag in the desktop file for now, and we intend to support that mir surface flag soon
[12:20] <greyback_> as he's doing all the rotation work manually it appears
[12:20] <dandrader> greyback_, that person is already using the desktop file parameter
[12:21] <greyback_> dandrader: but is she using it correctly?
[12:22] <dandrader> greyback_, she's is locking to some orientation in the desktop file and rotating the ui internally according it the user's preference. so what she wants is the runtime preferred orientation. not the list of supported ones (from the desktop file)
[12:26] <tsdgeos> dandrader: do you know the command line to start unity8 on the phone manually?
[12:28] <greyback_> MIR_SERVER_NAME=session-0 \
[12:28] <greyback_> MIR_SOCKET=/run/mir_socket QT_QPA_PLATFORM=mirserver  /usr/bin/unity8
[12:28] <greyback_> tsdgeos: ^^
[12:28] <greyback_> dandrader: ok I understand
[12:29] <greyback_> dandrader: yeah, point her to bug 1379777 (I renamed it to be more clear)
[12:32] <tsdgeos> tx
[13:39] <dandrader> greyback_, do you understand why it failed? http://paste.ubuntu.com/12048029/
[13:40] <dandrader> greyback_, is it the weird path to the desktop file?
[13:40] <greyback_> dandrader: https://code.launchpad.net/~gerboland/qtmir/fix-desktop_file_hint/+merge/267504
[13:40] <dandrader> greyback_, was doing "qmlscene foo.qml --desktop_file_hint=[...]"
[13:40] <dandrader> greyback_, yeah, I'm testing that
[13:40] <dandrader> greyback_, get this failure with or without it
[13:41] <greyback_> dandrader: the ".desktop" has been removed from the path in the second line of that log
[13:41] <greyback_> my patch was supposed to prevent that happening
[13:42] <dandrader> greyback_, the problem is the path
[13:42] <greyback_> dandrader: why?
[13:42] <dandrader> greyback_, passing something simpler like --desktop_file_hint=/usr/share/applications/dialer-app.desktop works
[13:42] <greyback_> we're not imposing the xdg standard paths
[13:42] <greyback_> in the desktop_file_hint stuff
[13:43] <greyback_> ok, I'll revisit
[13:43] <dandrader> greyback_, as far as I understood your patch is just a cosmetic change. doesn't change any behavior, or does it?
[13:44] <dandrader> (ie, fixes some sneaky bug caused by the inplace modification of that string)
[13:49] <greyback_> dandrader: bug was the QString::remove() actually alters the string, so we were always removing the ".desktop" from the path, before checking is it exists.
[13:50] <greyback_> instead I split the string into a string list, then removed ".desktop" from the last one. That will leave the original path untouched
[13:50] <greyback_> s/is/does/
[13:50] <greyback_> I'll try figure out why your longer path fails
[13:50] <dandrader> greyback_, as I posted on the MP, I didn't spot any behavioral change with this patch. so approved
[13:51] <dandrader> (as in no regressions)
[13:51] <greyback_> dandrader: well while I'm at it, I'll try fix your problem too
[13:56] <dandrader> ltinkl, about your "Use QFile::encodeName(file) and theme.toUtf8().constData()"  comment
[13:56] <ltinkl> dandrader, yes
[13:57] <dandrader> ltinkl, the theme string is also used to build the full file path. So no sense in making it utf8
[13:57] <dandrader> ltinkl, so what you would like me to use instead?
[13:57] <dandrader> ltinkl, ie, theme will be directory name
[13:57] <ltinkl> dandrader, do you have a link handy to the comment? can't find the code now
[13:57] <dandrader> ltinkl, https://code.launchpad.net/~dandrader/qtmir/mousePointer/+merge/266919
[13:59] <dandrader> and QFile::encodeName feels a bit like overkill. All I want is plain ASCII chars
[14:00] <dandrader> but it kinda makes sense, so I won't oppose using it
[14:00] <ltinkl> dandrader, so if I have a custom cursor theme in my home directory (/home/lukáš/.icons) it won't break? :)
[14:00] <ltinkl> dandrader, it will imo
[14:01] <ltinkl> dandrader, and if the theme name is used to build up the path, then QFile::encodeName() too
[14:01] <ltinkl> dandrader, using UTF8 user names is perfectly legal
[14:02] <dandrader> ltinkl, it's blasphemous!
[14:02] <dandrader> :)
[14:02] <ltinkl> dandrader, sad story tho, a lot of SW breaks with it but we don't want it, don't we? :)
[14:04] <dandrader> ltinkl, done
[14:09] <ltinkl> dandrader, cool, so when are native cursors coming to Mir itself?
[14:10]  * ltinkl brb
[14:11] <dandrader> ltinkl, already has it. problem is that it's not easy to manipulate it from untiy8/qtmir at the moment. it misses all the nice context information you get by having it as a qml item inside unity8's scene
[14:12] <dandrader> ltinkl, but we will change qtmir's implementation to use it once it's as flexible as we need it to
[14:13] <dandrader> ltinkl, eg: it's completely oblivious to unity8 scene rotation for instance
[14:15] <ltinkl> dandrader, https://code.launchpad.net/~lukas-kde/unity8/globalshortcuts/+merge/267188/comments/671668 any idea there?
[14:20] <dandrader> ltinkl, a Loader is a FocusScope
[14:20] <dandrader> ltinkl, so It might just be a matter of setting "focus = true" on that dialog loader
[14:20] <ltinkl> dandrader, tried that and many other things actually :)
[14:21] <ltinkl> dandrader, it just won't work
[14:21] <dandrader> ltinkl, and having "focus: true" on the dialog as well
[14:21] <ltinkl> dandrader, yup, that too
[14:22] <dandrader> ltinkl, ok. I'll investigate it then
[14:23] <ltinkl> dandrader, thanks
[14:23] <dandrader> ltinkl, by the way, having that many event filters attached to the window does scare me a bit. it might impact performance
[14:23] <ltinkl> dandrader, ye... I'll think of consolidating them somehow
[14:23] <dandrader> as each GlobalShortcut item is a separate window event filter
[14:23] <ltinkl> wait
[14:24] <ltinkl> dandrader, it isn't
[14:24] <ltinkl> dandrader, there's just one in GlobalShortcutRegistry::eventFilter
[14:24] <dandrader> hmm
[14:25] <ltinkl> I made it that way exactly for this reason
[15:16] <a1fa> greyback_:
[15:16] <a1fa> you here?
[15:16] <a1fa> https://bugs.launchpad.net/unity/+bug/1483014
[15:21] <greyback_> a1fa: I've replied, I asked for more info about your physical setup would be useful
[15:21] <a1fa> i did not see
[15:21] <greyback_> F5 should show it
[15:21] <a1fa> refresh? i still dont see any updates
[15:22] <a1fa> were you able to replicate the bug? i found a way to replicate it everytime
[15:23] <a1fa> ok i see it now
[15:23] <a1fa> :)
[15:23] <a1fa> wrote 2 minutes ago :)
[15:23] <greyback_> a1fa: ok good
[15:26] <a1fa> i'm at work at the moment. is there a way to dump apport info into a file ?
[15:28] <greyback_> a1fa: that doesn't appear to be possible, sorry
[15:29] <a1fa> do you need my Xorg.conf?
[15:29] <greyback_> a1fa: yes, I can reproduce it
[15:29] <a1fa> awesome!
[15:29] <greyback_> a1fa: good instructions
[15:29] <a1fa> hopefully it is not driver-specific
[15:30] <greyback_> I'm using intel
[15:30] <greyback_> it does smell of a unity bug
[15:30] <a1fa> i started trying to break it, because it was happening once in a while and i dont know what i did
[15:30] <a1fa> so i started paying attention to my clicks, and bam
[15:30] <a1fa> it also happens with TAB
[15:30] <a1fa> TAB show desktop
[15:31] <a1fa> ALT=TAB
[15:31] <greyback_> for some reason that window becomes invisible, and on selecting it, unity doesn't figure out it's been made visible and so should draw decorations
[15:44] <ltinkl> dandrader|afk, addressed your comments in the globalshortcuts MP
[15:51] <greyback_> dandrader|afk: weird thing, desktop_file_hint=/usr/share/click/preinstalled/com.ubuntu.clock/3.4.305/share/applications/ubuntu-clock-app.desktop works for me, but not with gallery. Very odd...
[15:52] <greyback_> aha, gallery-app.desktop" is not valid - check its syntax, and that the binary specified by the Exec line is installed!
[15:52] <greyback_> the Exec line points to a binary with relative path, which gdk not happy about
[15:53] <greyback_> that's a different issue
[16:08] <dandrader> greyback_, ah, ok
[16:34] <ltinkl> dandrader, onLogoutReady fixed too
[20:11] <josharenson> ted: Do you know how processes are killed by the OOM Killer when the scores are tied? (re: https://bugs.launchpad.net/ubuntu/+source/ubuntu-app-launch/+bug/1478853/comments/10)
[20:14] <ted> josharenson, It is not simple, but usually by memory size.
[20:14] <ted> There are things like last used CPU and stuff in there as well.
[20:14] <josharenson> ted: thats what I figured, wish it took into account when the app was last focused too
[20:15] <josharenson> seems like it could be helpful w/ the bug
[20:15] <ted> josharenson, In general, last focused and last CPU are roughly the same.
[20:15] <josharenson> ted: ah ok
[20:15] <ted> It can't use CPU when not focused.