/srv/irclogs.ubuntu.com/2015/08/10/#ubuntu-unity.txt

=== faenil is now known as faenil_
tsdgeoscimi: 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:06
tsdgeoscimi: greyback: unfortunately we need an answer "now" since otherwise pstolowski can't land stuff09:07
greybacktsdgeos: qtmir hasn't changed yet, if that's the part of the stack you're referring to09:07
cimi:/09:07
tsdgeosgreyback: no, i mean all the unity-* stuff09:07
cimisaviq and mzanetti wanted to avoid that09:08
pstolowskigreyback, no, just scopes stuff and plugin09:08
pstolowskicimi, we all wanted to, but i'm not sure how it is possible09:08
greybackpstolowski: the code will be the same, it's just the ABI of the binaries will be different, yeah?09:09
pstolowskicimi, here is what i get when trying to land just vivid overlay https://requests.ci-train.ubuntu.com/static/dashboard.html#?q=ubuntu%2Flanding-00509:09
greybackbut the binary lib names will need to be different09:09
pstolowskigreyback, yes, and it will affect deb packaging (debian/control)09:09
greybackpstolowski: why?09:10
pstolowskigreyback, package names need to reflect that change afaik09:11
=== faenil_ is now known as faenil
greybackpstolowski: 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 there09:12
greybackI'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 stuff09:13
pstolowskigreyback, isn't it essentially the same as what we get with 2 trunks?09:15
pstolowskigreyback, ah, ok got you09:15
greybackpstolowski: I don't like the phrase "2 trunks" :)09:15
pstolowskigreyback, i know, that's a synonym of pain09:17
pstolowskigreyback, in any case... we need a solution fast, ota is really close :/09:17
tsdgeosso09:22
tsdgeosdo we go that way? or anyone wants to call on the phone michael or saviq and annoy them with this?09:22
greybackpstolowski: so I believe you can fix your build with https://code.launchpad.net/~gerboland/unity8/changelog-update-gcc5/+merge/26686109:22
greybacktsdgeos: I think we should just focus on landing for vivid+overlay, until all this mess is understood09:23
tsdgeosgreyback: so you want lp:unity8 to be basically vivid-overlay targettd instead of wily?09:24
greybackthat goes against the "land in devel first" thing though, so need to check with CI folk it's acceptable09:24
pstolowskigreyback, we want to land vivid only atm09:24
greybackok09:25
greybacktsdgeos: I think that's the route of least difficulty for now09:25
tsdgeosi'm fine with that09:25
tsdgeosbut pstolowski says debian stuff complains about version numbers being smaller09:25
tsdgeossince if we do a vivid overlay landing only it creates 15.04 vs 15.10 or something09:25
tsdgeosgreyback: does the branch you pointed help with that?09:26
pstolowskiit'll still complain about 15.10 there i think09:26
greybackpstolowski: I used that in my silo 19, and it kept the train quiet09:27
greybackreason is that there's the added changelog entry in the release branch: https://code.launchpad.net/~ubuntu-branches/ubuntu/wily/unity8/wily09:27
pstolowskihmm09:27
pstolowskigreyback, but if it works, this will update changelog with 'vivid' entry, in trunk. that's going to create problems, no?09:28
greybackI think if we sync that back to trunk, we should be ok. That's what my branch above does09:28
greybackpstolowski: frankly, I don't care about wily that much right now09:29
pstolowskiah, ok09:29
greybackwe're landing something newer anyway, so the old version isn't so useful then09:29
greybackpstolowski: can you try adding that branch to your silo, and see if the train is happy?09:30
pstolowskigreyback, ok09:30
greybackpstolowski: thanks09:30
pstolowskigreyback, 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:31
greybackpstolowski: it might, as it appears bzr compares the version strings before merging09:32
greybackpstolowski: but if one lands, then this trouble should go away09:33
tsdgeosyeah let's go that way for now09:33
tsdgeosand see how to "fix it properly" later09:33
tsdgeosi guess09:33
greybackyeah. 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 do09:34
pstolowskiallright09:37
cimigreyback, tsdgeos we can do like uitk they have staging09:38
tsdgeoscimi: that doesn't help in this regard09:38
tsdgeosthe problem we have is that we'll eventually need two branches because the dependencie names are going to change09:39
tsdgeosor that's what i understood09:39
greybacktsdgeos: 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:41
greybackI am still not clear on why that demands a different package name though, I need to think more perhaps09:42
tsdgeosgreyback: the thing is, since we don't maitain soversion09:43
tsdgeoswe need different package names09:43
tsdgeosor bump the one in wily by 10009:43
tsdgeosso that if we need to break the soversion again in vivid we don't end up on one that we used already for wily09:44
pstolowskigreyback, i think just the version number doesn't prevent stuff from breaking, i think we need libfoo3 to become libfoo4 etc09:44
tsdgeosam i making sense?09:44
greybackpstolowski: yeah I think you're right09:44
greybacktsdgeos: yep09:44
greybackI'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 dependencies09:51
tsdgeosgreyback: so 3 branches in maintaince at a time?09:57
tsdgeosat least09:57
tsdgeos"development", "unstable release" and "vivid+overlay"09:57
greybacktsdgeos: effectively. With devel having the least maintenance burden naturally10:00
tsdgeosright10:00
pstolowskigreyback, still fails https://requests.ci-train.ubuntu.com/static/dashboard.html#?q=ubuntu%2Flanding-00510:12
pstolowskigreyback, the problem is with 15.04... vs 15.10.. version string10:13
pstolowskigreyback, so i solved similar issue for my branches by manually changing the topmost changelog entry to say 15.04, vivid in my 15.04-trunks10:14
greybackpstolowski: hmmm, I dislike having to do that tho10:19
pstolowskigreyback, the only 'workaround' is to bump the real package version number, but that hides the problem10:20
pstolowskigreyback, 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 tbh10:22
greybackpstolowski: bumping the version number is ok IMO10:23
greybackwe shouldn't have this problem again any time soon10:23
pstolowskigreyback, ok.. as i mentioned earlier we do this in silo 27 already, bumping unity8 to 8.1110:23
greybackpstolowski: yeah, I'm ok with that10:23
greybackgo for it10:24
pstolowskigreyback, ok, in that case your gcc5 branch my not be needed if we rebuild and land our two silos in correct order10:24
greybackpstolowski: yeah, I'll drop it since you'll have everything fixed for me :)10:25
=== guest42345 is now known as y
* pstolowski wishes he can focus on real coding10:25
=== y is now known as Guest82082
pstolowskisil2100, 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 being10:44
greybackwe will work out a more comprehensive landing strategy,  but for now we want to land stuff for vivid+overlay10:45
sil2100greyback, pstolowski: is unity8 still able to dual-land?10:48
greybacksil2100: 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 change10:49
tsdgeosdamnit i cant' get untiy8 to crash on the desktop anymore as it was crashing 15 min ago10:49
* tsdgeos puzzled10:49
pstolowskisil2100, yes, as greyback says. we have changes in shell plugin and unity-api which need changing for gcc5 symbols changes (+ packaging changes)10:50
pstolowskisil2100, and this goes further down to mediascanner lib10:50
pstolowskisil2100, i10:51
pstolowskisil2100, i've separate trunks for 15.04 for these projects10:52
sil2100hmmm10:54
=== JMulholland_ is now known as JMulholland
=== alan_g is now known as alan_g|lunch
dandradergreyback_, do you know where's the bug we have about supporting apps preferred orientation?12:14
dandradergreyback_, ie, an app telling us the orientation it would like to be in at runtime12:15
dandradergreyback_, I recall we had a bug about it but could not find it12:15
greyback_dandrader: I think this is all we've got https://bugs.launchpad.net/qtmir/+bug/137977712:17
ubot5Ubuntu bug 1379777 in Ubuntu UX "[Orientation] Allow applications to specify the orientations supported" [High,Fix released]12:17
greyback_which links to https://bugs.launchpad.net/mir/+bug/138220912:17
ubot5Ubuntu bug 1382209 in qtmir (Ubuntu) "[Enhancement] Add an API to lock surface orientation" [Undecided,New]12:17
greyback_which shows the mir work is done at least12:17
dandraderhmmm12:18
dandraderI'm asking this because of the last comment in https://bugs.launchpad.net/qtmir/+bug/137977712:18
ubot5Ubuntu bug 1379777 in Ubuntu UX "[Orientation] Allow applications to specify the orientations supported" [High,Fix released]12:18
dandradergreyback_, would like to point that person to the "set runtime preferred orientation" bug12:19
dandradergreyback_, so maybe we can use https://bugs.launchpad.net/mir/+bug/1382209 for it12:19
ubot5Ubuntu bug 1382209 in qtmir (Ubuntu) "[Enhancement] Add an API to lock surface orientation" [Undecided,New]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 soon12:19
greyback_as he's doing all the rotation work manually it appears12:20
dandradergreyback_, that person is already using the desktop file parameter12:20
greyback_dandrader: but is she using it correctly?12:21
dandradergreyback_, 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:22
tsdgeosdandrader: do you know the command line to start unity8 on the phone manually?12:26
greyback_MIR_SERVER_NAME=session-0 \12:28
greyback_MIR_SOCKET=/run/mir_socket QT_QPA_PLATFORM=mirserver  /usr/bin/unity812:28
greyback_tsdgeos: ^^12:28
greyback_dandrader: ok I understand12:28
greyback_dandrader: yeah, point her to bug 1379777 (I renamed it to be more clear)12:29
ubot5bug 1379777 in Ubuntu UX "[Orientation] Allow applications to specify the orientations supported" [High,Fix released] https://launchpad.net/bugs/137977712:29
tsdgeostx12:32
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
=== alan_g|lunch is now known as alan_g
dandradergreyback_, do you understand why it failed? http://paste.ubuntu.com/12048029/13:39
dandradergreyback_, is it the weird path to the desktop file?13:40
greyback_dandrader: https://code.launchpad.net/~gerboland/qtmir/fix-desktop_file_hint/+merge/26750413:40
dandradergreyback_, was doing "qmlscene foo.qml --desktop_file_hint=[...]"13:40
dandradergreyback_, yeah, I'm testing that13:40
dandradergreyback_, get this failure with or without it13:40
greyback_dandrader: the ".desktop" has been removed from the path in the second line of that log13:41
greyback_my patch was supposed to prevent that happening13:41
dandradergreyback_, the problem is the path13:42
greyback_dandrader: why?13:42
dandradergreyback_, passing something simpler like --desktop_file_hint=/usr/share/applications/dialer-app.desktop works13:42
greyback_we're not imposing the xdg standard paths13:42
greyback_in the desktop_file_hint stuff13:42
greyback_ok, I'll revisit13:43
dandradergreyback_, as far as I understood your patch is just a cosmetic change. doesn't change any behavior, or does it?13:43
dandrader(ie, fixes some sneaky bug caused by the inplace modification of that string)13:44
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:49
greyback_instead I split the string into a string list, then removed ".desktop" from the last one. That will leave the original path untouched13:50
greyback_s/is/does/13:50
greyback_I'll try figure out why your longer path fails13:50
dandradergreyback_, as I posted on the MP, I didn't spot any behavioral change with this patch. so approved13:50
dandrader(as in no regressions)13:51
greyback_dandrader: well while I'm at it, I'll try fix your problem too13:51
dandraderltinkl, about your "Use QFile::encodeName(file) and theme.toUtf8().constData()"  comment13:56
ltinkldandrader, yes13:56
dandraderltinkl, the theme string is also used to build the full file path. So no sense in making it utf813:57
dandraderltinkl, so what you would like me to use instead?13:57
dandraderltinkl, ie, theme will be directory name13:57
ltinkldandrader, do you have a link handy to the comment? can't find the code now13:57
dandraderltinkl, https://code.launchpad.net/~dandrader/qtmir/mousePointer/+merge/26691913:57
dandraderand QFile::encodeName feels a bit like overkill. All I want is plain ASCII chars13:59
dandraderbut it kinda makes sense, so I won't oppose using it14:00
ltinkldandrader, so if I have a custom cursor theme in my home directory (/home/lukáš/.icons) it won't break? :)14:00
ltinkldandrader, it will imo14:00
ltinkldandrader, and if the theme name is used to build up the path, then QFile::encodeName() too14:01
ltinkldandrader, using UTF8 user names is perfectly legal14:01
dandraderltinkl, it's blasphemous!14:02
dandrader:)14:02
ltinkldandrader, sad story tho, a lot of SW breaks with it but we don't want it, don't we? :)14:02
dandraderltinkl, done14:04
ltinkldandrader, cool, so when are native cursors coming to Mir itself?14:09
* ltinkl brb14:10
dandraderltinkl, 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 scene14:11
dandraderltinkl, but we will change qtmir's implementation to use it once it's as flexible as we need it to14:12
dandraderltinkl, eg: it's completely oblivious to unity8 scene rotation for instance14:13
ltinkldandrader, https://code.launchpad.net/~lukas-kde/unity8/globalshortcuts/+merge/267188/comments/671668 any idea there?14:15
dandraderltinkl, a Loader is a FocusScope14:20
dandraderltinkl, so It might just be a matter of setting "focus = true" on that dialog loader14:20
ltinkldandrader, tried that and many other things actually :)14:20
ltinkldandrader, it just won't work14:21
dandraderltinkl, and having "focus: true" on the dialog as well14:21
ltinkldandrader, yup, that too14:21
dandraderltinkl, ok. I'll investigate it then14:22
ltinkldandrader, thanks14:23
dandraderltinkl, by the way, having that many event filters attached to the window does scare me a bit. it might impact performance14:23
ltinkldandrader, ye... I'll think of consolidating them somehow14:23
dandraderas each GlobalShortcut item is a separate window event filter14:23
ltinklwait14:23
ltinkldandrader, it isn't14:24
ltinkldandrader, there's just one in GlobalShortcutRegistry::eventFilter14:24
dandraderhmm14:24
ltinklI made it that way exactly for this reason14:25
=== dandrader is now known as dandrader|afk
a1fagreyback_:15:16
a1fayou here?15:16
a1fahttps://bugs.launchpad.net/unity/+bug/148301415:16
ubot5Ubuntu bug 1483014 in Unity "Unity Launcher and Terminal Windows" [Undecided,New]15:16
greyback_a1fa: I've replied, I asked for more info about your physical setup would be useful15:21
a1fai did not see15:21
greyback_F5 should show it15:21
a1farefresh? i still dont see any updates15:21
a1fawere you able to replicate the bug? i found a way to replicate it everytime15:22
a1faok i see it now15:23
a1fa:)15:23
a1fawrote 2 minutes ago :)15:23
greyback_a1fa: ok good15:23
a1fai'm at work at the moment. is there a way to dump apport info into a file ?15:26
greyback_a1fa: that doesn't appear to be possible, sorry15:28
a1fado you need my Xorg.conf?15:29
greyback_a1fa: yes, I can reproduce it15:29
a1faawesome!15:29
greyback_a1fa: good instructions15:29
a1fahopefully it is not driver-specific15:29
greyback_I'm using intel15:30
greyback_it does smell of a unity bug15:30
a1fai started trying to break it, because it was happening once in a while and i dont know what i did15:30
a1faso i started paying attention to my clicks, and bam15:30
a1fait also happens with TAB15:30
a1faTAB show desktop15:30
a1faALT=TAB15: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 decorations15:31
ltinkldandrader|afk, addressed your comments in the globalshortcuts MP15:44
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:51
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 about15:52
greyback_that's a different issue15:53
=== dandrader|afk is now known as dandrader
dandradergreyback_, ah, ok16:08
=== Malsasa_ is now known as Malsasa
ltinkldandrader, onLogoutReady fixed too16:34
=== Malsasa_ is now known as Malsasa
=== alan_g is now known as alan_g|EOD
=== dandrader is now known as dandrader|afk
=== cwayne-afk is now known as cwayne
=== dandrader|afk is now known as dandrader
josharensonted: 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:11
ubot5Ubuntu bug 1478853 in ubuntu-app-launch (Ubuntu) "OOM scoring kills the browser's render process while the browser is running" [Critical,Confirmed]20:11
tedjosharenson, It is not simple, but usually by memory size.20:14
tedThere are things like last used CPU and stuff in there as well.20:14
josharensonted: thats what I figured, wish it took into account when the app was last focused too20:14
josharensonseems like it could be helpful w/ the bug20:15
tedjosharenson, In general, last focused and last CPU are roughly the same.20:15
josharensonted: ah ok20:15
tedIt can't use CPU when not focused.20:15

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!