=== salem_ is now known as _salem [01:01] looking for a working solution to get unity back online with geforce 210 [01:02] I tried at least 6 or 7 different approaches so far [01:02] ubuntu 12.10 [01:44] Does anyone here know what the specific config files are for both of the Panels and the window decorations for Unity? I have had temporary success moving different folders out of ~/.config [01:45] I am having issues with no Unity panels and window decorations.... === _salem is now known as salem_ [01:50] I have absolutely no Unity panels, and no window decorations ( I can open a terminal using Ctrl+Alt+T to run the command gnome-session-quit). [01:53] Guest88134: That usually means you're missing the decor and unityshell plugins. Try running ccsm and tick the boxes to enable them. [02:00] duflu: well... this is a bit more complicated I suppose.... I am running LTS fine and Raring is missing the panels, etc.... I have tried ccsm, and unity-tweak-tool.... but to no avail. my testing user has everything. [02:01] there is something wrong with the way raring reads the config files. I am using the same ~/ for both installations [02:01] Guest88134: OK, I have a simple command for literally deleting all compiz/unity customisations from your config. Let me try and find it [02:02] duflu: thanks.... is there a way to make Raring use its own config files somewhere else other than the ~/.config /? [02:03] Guest88134: Since quantal, the config has been in gsettings. That's a binary database you can't edit by hand. Let me try to find the old command [02:03] I mean, gsettings uses "dconf", which is a binary database [02:05] duflu: Ok... so are you saying I CAN use dconf editor to make Raring use something... all the while LTS will use something else? or are you saying something entirely different... [02:05] Guest88134: For quantal/raring: dconf reset -f /org/compiz/ [02:06] Guest88134: For precise, it was gconf (different tools) [02:06] duflu: ok... I kept trying to do stuff like compiz --replace unity --replace unity --reset, etc... until it would lock up. [02:07] Guest88134: That dconf reset will just delete all compiz/unity customisations. And you will get the default setup like Guest does [02:07] So Precise shouldn't be effected by this?? [02:07] No, precise used gconf :( [02:07] Potentially similar problems, but different commands [02:10] duflu: cool thanks, precise has been fine.... I will test this and I'll come back and tell you if something went awry [02:21] duflu: OK... I'm back... last time my name was Guest88134. That did not work. I did reboot and check and my precise install is still working just fine. [02:21] love_: OK then please take a copy of ".xsession-errors" and put it in a new bug report on Launchpad :( [02:22] That file is in your home directory. Remember to copy it _while_ you're logged in [02:22] duflu: I did start a bug... I'll attach the file thanks. [02:24] duflu: Oh... look at this... I/O warning : failed to load external entity "/home/love/.compiz/session/" [02:25] love_: It's likely not the cause because those errors are common. But you should be able to safely delete the .compiz directory too. That might be part of the issue [02:26] I have done that before to temporarily fix it...... I am just wondering if there could be a workaround.... [02:26] The ~/.compiz dir only causes problems if you're been compiling your own compiz plugins [02:27] love_: Deleting that plus the dconf reset may be the fix [02:27] nope... I don't even use the cube or any of that anymore.... either unity w/ compiz of Lxde with xcompmgr for the transparent terminal [02:27] duflu: Ok. I will try that and let you know [02:38] duflu: nope. I guess I will go fishing with my bug report.... thanks for the help, though!!! [02:38] love_: No problem. What bug number? [02:40] https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1128348 [02:40] Launchpad bug 1128348 in unity (Ubuntu) "Unity starts without panels" [Undecided,Confirmed] [02:40] duflu: it took me a bit to find it... [02:42] love_: Please attach the .xsession-errors [02:43] duflu: in the process.... I had to rename it so I could find it in the attachments dialog [03:06] duflu: did you have a chance to look at it yet? [03:06] love_: Not yet but soon [03:07] duflu: ok thanks :) === salem_ is now known as _salem [03:37] love_: If that log file came from raring then your problem is that you've somehow made compiz start using gconf instead of gsettings [03:37] * duflu boots raring to double check it's still gsettings [03:39] duflu: the other file didn't have anything in it except stuff about this current LXDE session.... I can logout, and log into Unity... then logout and check that... [03:40] love_: I'll move the discussion to the bug and add comments there [03:41] Ok... that will be easier. I need to do something else in a little bit... so I will check this out and post in the bug report if I find a different error file... [06:48] hey mmrazik [06:48] mmrazik: I got a question on https://code.launchpad.net/~unity-team/libunity/libunity-7.0 [06:48] mmrazik: seems that rev336 was merged by the server [06:48] merger* [06:48] however, in todays' daily build: https://launchpad.net/~ubuntu-unity/+archive/experimental-prevalidation/+build/4389883/+files/buildlog_ubuntu-raring-i386.libunity_6.91.4%7Edaily13.03.22ubuntu.unity.experimental.certified-0ubuntu1_FAILEDTOBUILD.txt.gz [06:49] the symbol check is normally exported in debian/rules [06:49] I'm puzzled how it passed, even if your env wasn't correct in the merger, it shouldn't :/ [06:49] let me find the jenkins job [06:50] yeah, build logs would be useful to understand what happens [06:51] didrocks: https://jenkins.qa.ubuntu.com/job/unity-team-libunity-libunity-7.0-raring-amd64-autolanding/12/console [06:52] mmrazik: dpkg-gensymbols: warning: debian/libunity9/DEBIAN/symbols doesn't match completely debian/libunity9.symbols [06:52] this should have failed the build [06:52] we are doing export DPKG_GENSYMBOLS_CHECK_LEVEL = 4 [06:52] in debian/rules [06:52] are you override that by any chance? [06:52] oh... [06:53] I might [06:53] I copy and pasted this without really understanding if if it is needed and for what [06:53] let me check [06:53] I still don't get it [06:53] it's in debian/rules [06:53] didrocks: it probably overrides debian/rules [06:53] so normally, it has higher priority and overwrite your env settings [06:53] ah? [06:54] didrocks: yeah... it does. Let me remove that hook completely. [06:54] sorry for that [06:54] mmrazik: yes please, remove it everywhere :) [06:54] should have checked with fginther [06:55] no worry! [06:55] glad we understand at least why :) [06:55] I was thinking about a direct push to trunk at first [06:55] mmrazik: I was doing that when we didn't have the packaging inlined [06:56] as we didn't force to update in sync [06:56] I see [06:56] now that we are inlined, I'm doing the other way and forcing to be synced :) === mmrazik is now known as mmrazik|afl === mmrazik|afl is now known as mmrazik|afk [07:48] didrocks, i have branch that updates the symbols === mmrazik|afk is now known as mmrazik === malin_ is now known as Malinux [07:51] mhr3: already in trunk, with bumping the changelog (I had to move it fast) [07:52] mhr3: should have been in sync, but didn't because of the above issue. Anyway, fixed now :) [07:52] didrocks, you pushed directly to trunk?! bad didrocks! :P [07:53] mhr3: had to unblock it, that's when we need to take actions sometimes :) [07:53] mhr3: and I bzr bd locally :p [07:53] (contrary to others, hem :p) [07:54] mmrazik: do you mind looking at ps-unity-100scopes-experimental-autopilot-release-testing/? [07:54] mmrazik: both ati and nvidia failed [07:54] didrocks: looking (but have a call in 5 mins) [07:55] ssh: connect to host dx-autopilot-ati port 22: Connection refused [07:55] mmrazik: let me rerun === alan_g is now known as alan_g|afk [08:44] hey ho [08:48] hmm, compiz crash with experimental ppa updated today [08:49] * popey tries to reproduce [08:49] yup [08:50] popey, stacktrace? [08:50] gnome-session[2705]: WARNING: Application 'compiz.desktop' killed by signal 11 [08:50] yeah, will do [08:55] seb128: http://paste.ubuntu.com/5636377/ [08:55] mhr3, ^ [08:55] dednick, ^ [08:56] mhr3, thanks ;-) [08:56] ping me if you need anything else from it [08:56] dunno why some computers don't like null pointers that much [08:56] :P [08:57] stupid computers [08:58] lets scrap null pointers, they're overrated [08:58] mhr3: you putting null pointers in the scope keyword list? ... [08:58] tsdgeos, https://code.launchpad.net/~unity-team/unity/phablet.build-hud-deps/+merge/154889 [08:59] dednick, are we? [08:59] Saviq: what was the problem you were having? [08:59] isn't just the keywords array null? [08:59] * dednick shrugs [08:59] tsdgeos, must have been VM [08:59] okidoki [08:59] tsdgeos, built fine in chroot [09:00] mhr3: the stacktrace seems to be compaining about string. and assumingly g_slist_next wouldnt return a valid pointer when operating on a null list. [09:00] but that's just assuming [09:00] oh [09:01] i'll check for it anyway [09:01] we have a raring autolander? [09:02] something's wrong :D [09:02] dependencies most probably [09:02] Saviq: mzanetti: https://jenkins.qa.ubuntu.com/job/unity-phablet-raring-armhf-autolanding/1/console [09:03] tsdgeos: hmmm... [09:04] tsdgeos: yeah... sergio enabled raring all over the place yesterday [09:04] ok :D [09:04] tsdgeos: of course all hell broke loose [09:05] dednick, where did you get that it's keywords though? i don't see full bt there [09:05] mzanetti: so we need some debian packaging massaging to get this working? [09:06] tsdgeos, I imagine it installs *unity from raring :/ [09:07] yeah "libunity9 armhf 6.90.2daily13.03.06.1-0ubuntu1" [09:07] and "libunity-core-6.0-5 armhf 6.12.0daily13.03.20-0ubuntu1" [09:07] tsdgeos: yep... we also have issues in the way we package autopilot tests (shell and apps)... need to fix that now. if you could try to fix the unity dep it'll be great [09:08] I wonder what can we do to stay on top of that... [09:08] Saviq: rename the package [09:08] and install it somewhere else [09:08] or merge back [09:08] somehow [09:08] mzanetti: i'm the worst person to fix that stuff, my .deb knowledge is →← [09:09] tsdgeos: well, make it two.... I guess the issue is more that the correct libs are not yet released [09:09] tsdgeos: so not really a packaging issue but more a releasing order thing I guess === alan_g|afk is now known as alan_g [09:09] i'd vote for "version number" [09:10] i mean in quantal is using [09:10] libunity9_6.12.0-0ubuntu0.1phablet3~quantal1_armhf.deb [09:10] while in raring is using [09:11] libunity9_6.90.2daily13.03.06.1-0ubuntu1_armhf.deb [09:11] mhr3: it seems to be the only string not protected by a null check [09:11] so your phablet version "loses" [09:11] s/your/our [09:12] dednick, it might not even be that method if something got inlined :) [09:13] Saviq: do you happen to know what are the differences we need in libunity? [09:13] tsdgeos, PeoplePreview for the most part [09:13] tsdgeos, in both libunity and unity-core [09:14] Saviq: too much work to "properly merge"? [09:15] tsdgeos, to merge upstream? probably, and then upstream is already working on the smart scopes rework... [09:16] dednick, looking at the code we add string only if they're length > 0, so definitely no nulls [09:16] *add strings only if their.... [09:16] Saviq: ok, so we find a different way to fix this [09:16] tsdgeos, yeah, we need to [09:16] mzanetti: Saviq: is shutting down the raring autolander out of scope? [09:17] tsdgeos, the build is going to switch to raring soon enough [09:17] mhr3: std::string value(static_cast(v->data); [09:17] cannot construct a string with null. will pop in strlen (which it does in the stack trace) [09:17] ok, so we need a fix :D [09:17] tsdgeos, so we should probably think about actually fixing it [09:18] dednick, hmm, look fine [09:18] s [09:18] wow, i need coffee [09:18] tsdgeos: yep... sergio wouldn't enable it just for fun... we really need to fix stuff [09:19] mzanetti: the phablet-ppa is there for the autolanders to use i understand, no? [09:19] tsdgeos: yes [09:21] so yeah, we just need to fix the " 6.12.0bzr213raring0 (Newer version available) " that shows up in https://launchpad.net/~phablet-team/+archive/ppa [09:21] trivial fix is just increasing the vNumber with no merge or anything [09:21] Saviq: does this ↑↑ work? [09:23] tsdgeos, briefly, I'd say... problem is libunity is used by "the other side", too (i.e. scopes) [09:23] hmmm [09:23] sooooo? :D [09:24] Saviq, tsdgeos: any of you might have an idea why this fails in raring ppa builders? https://pastebin.canonical.com/87511/ [09:24] doing the same call from a bash script works. seems to be cmake related [09:24] popey: you just using standard ppa? does it always pop? [09:24] mzanetti, [09:24] mzanetti, build-dep python [09:25] mzanetti, not python2.7 [09:25] mzanetti, [09:25] https://code.launchpad.net/~saviq/indicators-client/fix-raring-build/+merge/153447 [09:25] for example [09:25] Saviq: thanks... I still wonder why I can't reproduce here [09:25] mzanetti, because you have "python" installed [09:26] mzanetti, and not just "python2.7" [09:26] dednick: "standard ppa"? I'm using the experimental 100scopes one [09:26] dednick: http://paste.ubuntu.com/5636433/ [09:26] mzanetti, sbuild proved useful to debug that [09:26] but if I do a dpkg -S on that import file, it say its in python-distutilslib (or something like that) and according to the build log that one is pulled in by pathon2.7 too [09:27] popey: ta [09:28] didrocks, can we have you for 10 minutes please? [09:28] Saviq: in 30 minutes? [09:28] didrocks, works [09:28] Saviq: like, I'm in a hangout in 2 minutes :p [09:29] will ping you back then ;) [09:29] thanks [09:29] dednick: yes, it always pops [09:46] dednick, hey, where did "If you’ve installed all the qml plugins to local folders (not in the QML_INSTALL_IMPORT path) you may need to instruct qtcreator where to find the plugins." come from? did you have that issue? [09:47] Saviq: i did in qt creator. it doesnt seem to know about the ./plugins folder. This was just for qtcreator to be able to resolve the sybols [09:48] dednick, k I thought it was about something external to lp:unity/phablet [09:49] Saviq: nope. nothing to do with building/running. only local to qtcreator [09:51] dednick, sorry for my ignorance, but where in QtCreator did you set the path? :D [09:53] Saviq: in the qmlproject file. there is a importPaths key. (we should probably actually set this in lp:unity/phablet) [09:53] dednick, ah [09:53] dednick, yup [09:54] Saviq: available now! [09:54] didrocks, hangout? [09:55] Saviq: sure ;) [09:55] just paste a link [09:56] didrocks, https://plus.google.com/hangouts/_/581ff53bd4b4a1c0d9070050e50e7eb484fd4856 [09:56] mzanetti, tsdgeos, you might want to join in, too [09:56] if you can [09:56] * tsdgeos tries [10:05] didrocks, will the smart scope *unity get bumped to version 7, though? [10:05] Saviq: probably, I'm not 100% sure we should and the impact TBH [10:05] Saviq: but use 7.80 [10:06] didrocks, ok, thanks [10:06] Saviq: we'll make sure S will inline, even if we don't bump to 7 ;) [10:08] Saviq: you doing it, right? [10:08] tsdgeos, yeah [10:08] good [10:09] Saviq: https://code.launchpad.net/~mzanetti/unity/phablet-fix-python-dep/+merge/154898 [10:10] Saviq: fyi. working on 100scopes again. need to get some bugs sorted, then need to fix autopilot tests. probably wont get anything on UnityNext today again... [10:10] dednick, k [10:17] tsdgeos, can you add "plugins" to importPaths in the .qmlproject file? [10:18] Saviq: i'm not using qtcreator, maybe makes sense for someone else to? mzanetti? [10:18] tsdgeos, ah k [10:18] tsdgeos, what are you using? [10:18] poor's man text editor [10:18] kate [10:19] tsdgeos: you're not using qtcreator? thats the best piece of IDE ever made :D [10:19] ok... I use kate quite often too [10:20] mzanetti, approved [10:20] cheers. your's too :D [10:21] sbuild + shm = speed! [10:21] ==, even! [10:21] regarding the .qmlproject file... dunno. I never used them... always go for qmake or cmake directly as I never have qml only stuff [10:30] sil2100, Mirv: Hi. I've backported the grid-top-left-corner-miscalculation-fix to compiz/raring, please approve it: https://code.launchpad.net/~mc-return/compiz/compiz-raring.merge-fix1139835-grid-wrong-top-left-corner-calculation/+merge/154899 [10:40] tvoss, regarding testing... are we meant to test pure interfaces too? I thought just real implementations need to be tested. Just wondering about your comment on an MR. [10:42] MacSlow, I do see implementation in the MR :) [10:42] tvoss, touché :) [10:48] Woha! [10:48] What happened to MCR1? [10:52] Saviq, tvoss: you should be happy now with https://code.launchpad.net/~macslow/unity/phablet-bootstrap-notification-structure/+merge/154748 [11:01] MacSlow: I just read through this. It looks quite good but I'd like to ask you to adapt Qt coding style a bit more for Qt code [11:01] MacSlow: also, instead of marking every signal with Q_SIGNAL its common to use a "signals:" section [11:02] MacSlow: whereas Q_INVOKABLE methods with void return value should mostly be declared as "slots:" [11:03] MacSlow: for class Notification I'd prefer signals: and slots: instead of using the Q_KEYWORDS for a hundret times [11:04] MacSlow: also, include own headers before the Qt ones (to avoid some conflicts where std stuff breaks Qt makros in some rare cases) [11:05] mzanetti, ok thx [11:06] mzanetti, signals: and slots: is a bad idea, it clashes with a lot of things from the c++ std-library [11:07] * mzanetti is using signals and slots for 8 years now and it clashed once with a bluetooth stack that had a variable called signals [11:07] mzanetti, did you use boost::signals recently? :) [11:08] so I leave Q_* as is? [11:08] tvoss: no... if mixing boost it might be different... I don't consider that c++ std-library tho [11:08] mzanetti, fair enough, but I would think that boost::signals might well flow somewhere in the codebase [11:09] MacSlow: just saying... its more common in the qt world to use the signals: and slots: notation [11:09] MacSlow: and I agree with tvoss that there are cases where it can conflict... as long as you don't include boost stuff yourself I see chances quite low tbh [11:10] mzanetti, I rather go the safe (more change-proof) way then and leave it as it is now [11:11] MacSlow: fine with me... you will notice that all the other Qt code "looks different" though :D [11:12] mzanetti, yeah... but then I've seen both ways [11:19] popey: can you try dist-upgrade your experimental ppa again? looks like there is a new verison of unity in there. I reproduced with the one you had, but seems to have been fixed... [11:19] sure can dednick [11:21] MacSlow: this is how a long term Qt dev would write it: https://pastebin.canonical.com/87524/ (note that I'm not saying that you have to change it like this. But I'm a strong believer of consistency in coding styles) === mmrazik is now known as mmrazik|lunch [11:32] Saviq: i've approved your MR [11:32] s [11:33] tsdgeos, cheers [11:33] let's see what that results in... [11:35] yeah :D [11:38] hello :) I just realized I haven't upgrade my phone/chroot for a long time... any instructions on how to do it? [11:38] wrong channel [11:38] :p [11:41] ;p [11:43] seems okay dednick [11:43] thanks [11:44] popey: weird. dont know what was going on. [11:55] dednick: still get the problem where the dash often doesn't get focus, so keypresses are lost === mmrazik|lunch is now known as mmrazik [11:56] popey: I think it's fixed in unity trunk [11:56] or there is a branch proposed [11:56] groovy [11:56] so not a 100scopes issues in fact, I guess [11:57] but if you have time to double check that I didn't dream this morning… :) [11:58] you dream about unity? [11:58] You may want to see a mental health professional. [11:59] popey: I guess I should, indeed :) [11:59] I dreamt that I was pocking jibel for a UTAH issue TBH [11:59] and it happened this morning :) [12:00] ooh, you have "the sight" [12:00] what are the lottery numbers this weekend? [12:01] popey: if only… if only… :) === MacSlow is now known as MacSlow|lunch [12:25] hmm, where did MCR1 go, he updated LP 1 min ago :) [12:37] Saviq: should we mark "fix/improve build scripts" as DONE ? [12:38] Saviq: or there's still something you want to do? [12:38] tsdgeos, opinion: I don't like the thingy copying the ssh key [12:39] tsdgeos, I'd rather get rid of it (it caused at least some of kgunn's problems) [12:39] tsdgeos, and either let people do it themselves [12:39] tsdgeos, or maybe add another option to run_on_device [12:40] yep [12:40] -key path [12:40] or something [12:47] any javascript experts around? I've an object created like var application = {'name' : "Foo", desktopFile:"bla"}. Then it's assigned to some var qml properties (foo = application). [12:48] if I compare var a and var b, both having been assigned to application [12:48] with a == b [12:48] I get false [12:48] even though they hold/point to the same application var [12:48] because if I do a.desktopFile == b.desktopFile I get true [12:49] If I print each of them I get: "ModelObject(0x1cc1dc0) == [object Object] is false" [12:49] so they are not really the same thing. I wonder what's the difference === _salem is now known as salem_ === kgunnAFK is now known as kgunn === salem_ is now known as _salem [13:02] kgunn, MacSlow|lunch ping [13:03] kgunn: pong (while making a coffee) [13:07] dandrader, one of them is a ModelObject, the other is just a JS object with the same properties [13:08] dandrader, they're simply different types [13:10] Saviq, I think I got it. when I push a JS object (the [object Object]) onto a ListModel, that ListModel creates a ModelObject storing the same properties. As a ListModel holds ModelObject instances and not regular js objs, right? [13:10] a lot of magic happening behind the scenes :) [13:11] kgunn, up for a quick hangout? https://plus.google.com/hangouts/_/7a2b5e6fd3ee0ae56e48da542672de9bab0bf8a3?authuser=0&hl=en [13:11] greyback, ping [13:12] dandrader, yup [13:12] dandrader: pong [13:12] greyback, do you know details on how the switch between shell rendering and application rendering takes place on the device? [13:13] or not "details" but just what actually takes place [13:14] some context: I'm poking and testing Stage.qml [13:14] dandrader: sure, I do [13:15] dandrader: sorry in a meeting right now, I'll ping you when free [13:15] so while an application is being rendered, does it render directly to the framebuffer that is being shown or does always renders to an offscreen fb that shell then takes and composites? [13:15] tvoss: give me like 5 min [13:15] greyback, ok [13:16] kgunn, ack [13:19] sil2100, hey, if you have a chance, can you please have a look at https://launchpadlibrarian.net/134926716/buildlog_ubuntu-quantal-amd64.unity_7.80~phablet1_FAILEDTOBUILD.txt.gz [13:20] sil2100, and hopefully point me at the correct solution [13:29] tvoss: ready? sorry for the delay [13:30] kgunn, no worries, as long as you are dressed now :) https://plus.google.com/hangouts/_/7a2b5e6fd3ee0ae56e48da542672de9bab0bf8a3?authuser=0&hl=en [13:37] please mark hangout links with potentially naked people as "use at your own risk" or something like that [13:37] :D === MacSlow|lunch is now known as MacSlow [13:51] kgunn, tvoss: ping [13:53] Saviq: give me a moment [13:53] Saviq, MacSlow can you jump on here: https://plus.google.com/hangouts/_/7a2b5e6fd3ee0ae56e48da542672de9bab0bf8a3?authuser=0&hl=en ? [13:53] tvoss, one sec... [13:55] Saviq: ping [13:55] dednick, pong [13:56] cyphermox: ping [13:56] Saviq: i'm going to give the standup a miss if that's ok. dont have anything to report on the UnityNext side, and i'm pretty busy with the other things. [13:56] dednick, k [13:56] ta [14:00] Saviq: ping [14:00] tsdgeos, pong [14:01] Saviq: unity-core is not part of https://launchpad.net/~phablet-team/+archive/ppa/+packages ? [14:01] tsdgeos, unity-core is built from unity [14:01] tsdgeos, next page, btw [14:01] Saviq: ah there's more pages [14:01] ...D [14:03] Saviq: seen unity failed to build? [14:03] dandrader: back. A better person to ask about that would be loicm. He knows more about the lower-end bits [14:03] tsdgeos, yeah, investigating, it's _weird_ [14:03] oki [14:03] Saviq: shout if you want me to have a look too [14:08] tsdgeos, thing is... [14:08] tsdgeos, unless we've been building a more recent bamf in the PPA (/me checks) [14:08] no, we weren't [14:09] then I don't understand how it could ever have built... [14:10] the missing symbol was added in lp:bamf in r496 [14:10] and was never backported to lp:bamf/0.3 [14:11] so I don't understand how it could ever work... [14:12] ah wait [14:12] got it [14:12] bamf was built in the other ppa === greyback is now known as greyback|food === mmrazik is now known as mmrazik|otp [14:15] didrocks: sil2100: I'm working on fix for Unity 5.0 & 6.0 and wanted to get your opinion on getting this in as an SRU. [14:15] sure, what about it? [14:15] What's up? [14:16] Ok, here the branches: https://code.launchpad.net/~townsend/unity/no-window-decorations-5.0 & https://code.launchpad.net/~townsend/unity/no-window-decorations-6.0 [14:16] They are a partial backport of https://code.launchpad.net/~3v1n0/unity/switcher-glowing-decorations/+merge/134019 [14:18] Trevinho says in bug #1122478 that there are no regressions. [14:18] bug 1122478 in Unity 6.0 "Unity appears to enable decorations in _MOTIFY_WM_HINTS on its own" [Medium,In progress] https://launchpad.net/bugs/1122478 [14:19] ChrisTownsend: yeah, I can confirm it... We actually are using this in unity for months and nothing has been spotted so far [14:19] Trevinho: Yep, it works quite nice:) [14:19] tsdgeos, let's extract unity-core from lp:unity/phablet, what do you think? [14:20] Saviq: you mean not using it unity-core? [14:20] I'm letting lukasz looking at it for now, ping me if you need anything (but sounds legit to me) [14:20] didrocks: Ok, cool. Thanks! [14:20] tsdgeos, so we don't build the whole of unity [14:20] tsdgeos, just UnityCore, which is what we are doing in ./build anyway [14:21] Saviq: you mean adding unity-core code to the lp:unity/phablet repo? [14:21] tsdgeos, /me wrong [14:21] tsdgeos, let's extract it from lp:unity/phablet-mods [14:21] ChrisTownsend: I'll take care of it then, let me just note it down ;p [14:22] sil2100: Ok, cool. I'll get an MP ready for it and we'll go from there. [14:22] Saviq: so we create a new repo that only builds unity-core and that's the one we use in the ppa [14:22] makes sense [14:22] yup [14:23] Saviq: maybe we can even reuse lp:unity/phablet-mods just to build unity-core? [14:23] ChrisTownsend: awesome - the bug is SRUable so feel free to MR against 5.0 and 6.0, we'll prepare the bug descriptions and keep it on our radar [14:23] changing the debian compile files and that's it? [14:23] sil2100: Very good, thanks! [14:24] tsdgeos, CMakeLists.txt, too [14:24] right [14:24]