[09:17] didrocks: wasn't it so that you rejected http://bazaar.launchpad.net/~compiz-team/compiz-core/0.9.7/revision/3111 from precise SRU in the summer, and thus it should be reverted in the 0.9.7 branch as well? [09:17] I'm not sure if I remember right [09:17] it's not very useful patch anyway for SRU [09:17] Mirv: yeah, it's not really useful, if it's not in precise, you should revert it [09:18] didrocks: thanks, doing that, and yes it's not yet in precise and now won't be [09:18] thanks Mirv ;) [09:44] i have this issue with unity on ubuntu 12.04 that i cant reassign "semi-maximize". Should i give up or IS there a solution, yet hard to find? [09:47] please people.. gimme a hint atleast [10:04] Squarism, hey [10:05] If noone helps you here, askubuntu is good, or #ubuntu [10:07] philipballew, thanx man [10:09] Squarism, not a problem, === _salem is now known as salem_ === mmrazik is now known as mmrazik|lunch === dandrader is now known as dandrader|afk === mmrazik|lunch is now known as mmrazik === MacSlow is now known as MacSlow|lunch === dandrader|afk is now known as dandrader === mmrazik is now known as mmrazik|afk_for_ === MacSlow|lunch is now known as MacSlow [14:11] conscioususer, hi, what's up? [14:17] mpt: hi, I needed some guidelines on the sensitivity of menuitems, when the menubar is shared between different windows [14:18] https://wiki.ubuntu.com/MenuBar gives me some cases, but not all [14:18] conscioususer, I suggest you set up a parent model that makes sensitive the items that make sense regardless of which window is focused [14:19] Choosing some of those items might involve focusing, or even opening, a window that isn't focused right now [14:19] mpt: oh, that part is actually already coded, it's the "make sense" part I need to understand [14:19] conscioususer, what's the easiest way for me to see your current/intended menu structure? [14:20] daily PPA, branching trunk, or something else? (I'm running 12.10) [14:20] mpt: some cases are obvious.. quit is always sensitive, about too... preferences shouldn't be sensitive when you're on the preferences window [14:20] mpt: I have a branch suitable for 12.10, but the menus are actually incomplete... I thought I could start with some general guidelines [14:21] conscioususer, so Preferences would be sensitive normally, and the Preferences window would make it insensitive [14:22] mpt: it's cases like "refresh" that I'm not sure about... the effects are only visible on the main window, but I don't see why the user should be forbidden to do it from the settings window [14:22] conscioususer, yes, that's an example of an item that would focus the main window, and open it if it isn't open currently [14:22] mpt: and focus if it's open but not focused? [14:23] mpt: oh, sorry, that's what you saids [14:23] *said [14:24] mpt: what about "add account"? the whole process happens in a new window (wizard), but visually the effects will only be seen on the main one [14:25] mpt: "remove current account" depends on the account menubutton, which is on the main window, so I guess it must be insensitive on the prefs window [14:25] conscioususer, sorry if I'm ignorant, but shouldn't menu item sensitivity be correct automagically when you're using app. and win. actions properly? [14:26] mpt: yeah, and this is working, my questions to mpt are to decide which will be app and which will be win [14:26] larsu: ^ [14:27] conscioususer, ah, go ahead then :) [14:27] conscioususer, correct. You might focus the main window after the Add Account process finishes. Not because the command is tied to the window, but just because that's the easiest way to show that the command succeeded. [14:30] mpt: hmm, ok, I think I can follow this to deduce the other ones [14:31] conscioususer, ok, let me know if you'd like me to review anything later on. :-) [14:31] mpt: sure will :) [14:32] mpt: thanks a lot :) [14:32] np [14:32] mpt: GMenu is really making my life easier on this one. [14:33] cool. :-) You can thank desrt [14:35] mpt: I thank him for that and also for some bugs he and larsu helped me with recently :) [14:35] mpt: btw, if you eventually have some time I'm interested on your opinion on this: https://lists.launchpad.net/unity-design/msg10086.html [14:36] conscioususer, ha, I asked the same thing on irc a while ago. It's a tricky situation unfortunately :/ [14:36] conscioususer, an easy way to fix that is to stop showing the application name in the menu bar :-) [14:38] true, but then the whole name-becomes-window-buttons would have to be rethought [14:40] mterry: hey, how are you? [14:40] didrocks, hello! [14:40] good [14:41] mterry: I saw that in fact, for merging inline the packaging branch back to upstream, you did merge the branch itself, not just copy debian:c [14:41] debian/ ? [14:41] mpt, larsu: I wonder if this might be the last drop that will make the design team give up on the titlebar-panel fusion? ;) [14:41] didrocks, yeah [14:41] (this was not clear on the merge request with the diff) [14:41] mterry: ok, this gives me some interesting challenge :) [14:41] for the daily upload bits [14:41] didrocks, oh sorry :-/ I thought keeping some history was valuable [14:41] as it's walking up the tree since last release [14:42] mterry: yeah, I got why it was important [14:42] conscioususer, the design team? ;-) [14:42] mpt: but basically the first release of every component is closing "all the bugs" :p [14:42] conscioususer, I'd certainly welcome that... (even though I do like the general idea) [14:42] mterry: [14:42] mpt: you know what I meant :P [14:42] sorry mpt ;) [14:42] didrocks, all the bugs in the packaging branch? :) hmm [14:43] didrocks, blacklist those merges? [14:43] mterry: yeah, and as with the debcommit, you get the upstream ones listed [14:43] didrocks, I think I'm missing some context [14:43] mterry: well, not that easy [14:43] mpt: I was talking to mterry, so m and you spoke last, sorry ;) [14:43] ah [14:44] mterry: I would say, to avoid cripping all the upload, we can bootstrap by hand [14:45] mpt: larsu: I'm not worried about polly, as I won't use an appmenu, but we're about to see 90% of gnome apps present this issue :-/ [14:45] didrocks, meaning what? [14:45] mterry: listing the bug and make a MR with the magic stenza (which is needed anyway) [14:46] mterry: will discuss about it when we can enable the project for daily upload [14:47] mterry: not related, but I think you saw https://code.launchpad.net/~mterry/unity-lens-applications/sync-packaging/+merge/133401 ? [14:47] (didn't have the time to look at it) [14:48] didrocks, yeah I saw, will go back to it [14:48] thanks! :) [14:50] desrt: the GMenu XML parsing functions were dropped in Gio, but the docs on those were the only source I knew for the DTD... where I can find the DTD now? [14:51] conscioususer: i don't know. [14:52] i guess the gtkbuilder one didn't get updated? [14:52] ....i guess gtkbuilder doesn't even _have_ one? [14:52] hrmph. [14:53] desrt: I noticed some things changed... for example, I can't seem to use the less verbose mode anymore [14:53] didrocks, what things are using /usr/lib/nux/unity_support_test nowadays? [14:53] less-verbose mode of what? === dandrader is now known as dandrader|lunch [14:55] desrt: according to http://developer.gnome.org/gio/2.31/gio-GMenu-Markup.html, I can set menuitem attributes using XML attributes instead of full-fledged tags.. but in 12.10 (Gio 2.32) trying to do this gives me an error [14:56] ya. we dropped that [14:56] it was leading to problems [14:56] two problems, specifically: [14:56] 1) it was unclear how we would support that for non-strings [14:56] ? [14:56] ugly... [14:57] 2) it was unclear how we would support translation for that [14:57] ? [14:57] ugly... [14:57] so we had a system that only really worked for string-typed values that were not translatable [14:57] which was approximately nothing at all [14:57] so it got nixed [14:58] ah, makes sense [14:58] mterry: compiz itself is using it [14:58] desrt: ok, so I guess the XML string example in http://developer.gnome.org/gtk3/unstable/GtkApplication.html tells me pretty much everything I need to know? [14:59] i admit that some things would be nice as direct attributes... like 'action' [14:59] since it's always a non-translatable string [14:59] mterry: it needs to be unfortunately in a separate process [14:59] otherwise you can't reinitialize opengl forcing llvmpipe [14:59] conscioususer: crikey.... [14:59] conscioususer: it kinda scares me that blotpad gets included wholesale into the docs [15:00] desrt: well, that kinda helped me :) [15:00] conscioususer: well,it should [15:00] bloatpad is supposed to be a demo of all of the major features of GtkApplication [15:00] it's just kinda.... big :) [15:00] for a code sniplet [15:00] didrocks, yar. Only compiz? (Branch to move to dh9 will bring multiarch to nux, so I'm thinking of adding a toolsdir variable to the .pc file, but I need to know who else needs to look for that var) [15:03] mterry: yeah, only compiz + the source_xorg.py package hook [15:04] mterry: it seems that it's been added to other hooks as well [15:04] like graphic driver ones [15:04] desrt: agree, sometimes it's hard to find something specific... well, GtkApp *does* have a ton of different features [15:04] didrocks, do you have a way to find out which by any chance? [15:05] conscioususer: it will have more soon :) [15:05] desrt: cool, I look forward to that... as long as they work on GC-languages :P [15:06] mterry: I don't really know, I only did the xorg one :) I found the nvidia ones by grepping in /usr/share/apport/package-hooks/ evn if I don't use it. Maybe some are installed by default? [15:06] k [15:55] fginther: can you have a look at https://code.launchpad.net/~didrocks/bamf/rev/+merge/134052 please? [15:58] didrocks, lookinv [15:58] looking === mmrazik is now known as mmrazik|otp === dandrader|lunch is now known as dandrader [16:18] didrocks, hi, i doubt this compiles [16:18] ricotz: ? [16:19] 1878 - if (!bamf_view_user_visible (BAMF_VIEW (window))) [16:19] 1879 + if (!bamf_view_is_user_visible (BAMF_VIEW (window))) [16:19] this isnt part of 0.3 irc [16:19] ricotz: I don't care about the content, this was a test, see the comment on other merge request [16:19] ah sorry [16:19] i thought this transition is going to 0.3 too [16:23] no worry :) [16:25] didrocks, I may be missing some context, are you really trying to merge that MP into lp:bamf/0.3? [16:26] lp:bamf/0.3 is still merging with unity-merger [16:28] fginther: I don't [16:28] fginther: just look at the comment [16:28] fginther: it's for the next daily workflow [16:28] fginther: so basically, there is changelog change only [16:29] didrocks, ok, so you want to push a release instead of an automatic build to staging ppa === mmrazik|otp is now known as mmrazik [16:37] fginther: not a real push [16:37] fginther: this can go to the traditional merge circuit [16:37] fginther: so doing bzr lp-propose --approved [16:37] fginther: but if I do that, there is no "approved revision" [16:38] like, you see the approval, but not the rev [16:38] is that an issue for you? [16:39] didrocks, thanks you, it's starting to make sense now. [16:42] didrocks, I think I understand better now. I'll need to investigate the launchpad API a bit to make sure we can correctly identify the merge proposal [16:42] fginther: thanks :) [16:42] mterry: kenvandine: cyphermox: hey, so… looking at this autolanding thing, it seems that some package (not mine, you ken! :p) doesn't have source package name == upstream project name [16:43] this gives a bunch of configuration nightmare that I want to avoid [16:43] do you think you can review each stack and ensure it's fine? [16:43] yeah [16:43] didrocks, #ubuntu-desktop dude :p [16:43] which package is that? [16:44] didrocks, sure [16:44] kenvandine: unity-lens-video! :-) [16:44] didrocks, I assume you prefer to rename the package in Ubuntu? [16:44] mterry: also, on the lens land, most of them finishes with a s [16:44] ugh [16:45] mterry: I don't really mind, as long as it's consistent :) [16:45] like all lenses finishing with a s [16:45] didrocks, hmmm. renaming LP projects is way easier. :) [16:45] but of course, no shoppings [16:45] mterry: does it work? [16:45] mterry: I looked at it [16:45] and it doesn't seem to be possible? [16:45] kenvandine: I want videos! :-) [16:45] didrocks, I think you have to ask LP admin to do it [16:45] mterry: oh oh [16:46] mterry: that can be interesting [16:46] kenvandine: what do you think? ^ [16:46] if LP renaming is an option, let's go for it [16:46] i'd prefer that [16:47] davidcalle, ^^ [16:47] didrocks, for some of them anyway. Like, the unity-lens-gdocs is upstream unity-scope-gdocs, so obviously we want to fix the scope mistake, and that's going to be in LP [16:47] mterry: kenvandine: cyphermox: each one taking care of their stack? :) [16:47] mterry: agreed [16:47] didrocks, that will still cause you configuration pain, I suppose, as all your scripts have to change to point [16:47] kenvandine, I can't see what you are pointing to :) [16:47] didrocks: ack [16:48] mterry: well, it's still better to just have one parameter than two, so I'll take care of that ;-) [16:48] davidcalle, we are talking about making the source package name and lp project match for the videos lens [16:48] kenvandine, mterry, cyphermox: if the LP branch names change, please let me know so that I can update the automerger jobs [16:49] kenvandine, ok. [16:49] fginther: ok [16:51] kenvandine, do you want me to poke a lp admin or will it be faster if it comes from your side? [16:51] i doubt it matters [16:51] it's your project though [16:51] so i would feel better if you did [16:52] kenvandine, ok [16:52] davidcalle, [16:52] davidcalle, thanks! [16:52] kenvandine, np! [17:09] kenvandine: mterry: so cyphermox came with setting -c4 by default [17:09] kenvandine: mterry: I think it's a nice idea (I have it for years on my desktop), next time we touch the packaging of any lib, what do you think about setting DPKG_GENSYMBOLS_CHECK_LEVEL=4 in the rules? [17:09] that avoid the dh_makeshlibs override [17:09] and force the value [17:09] didrocks: really, if it's done for the merges, it's more like belt + suspenders [17:10] cyphermox: I'm all for suspenders :) [17:11] didrocks, OK [17:12] mterry: I think though that we shouldn't activate that on the C++ projects, pitti and I spent a lot of time of trying to have symbols tracking on them and we never succeeded as we discussed at Copenhaguen [17:12] didrocks, oh god no. I hate symbols & c++ [17:12] bah, then maybe just forget about it and have everything pretty much the same [17:13] mterry: we all do! :-) everytime I'm reading http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++ and forget about those sneaky details… [17:13] cyphermox: we just can't have symbols file in c++ project, but I guess that's fine [17:14] thanks mterry, cyphermox, kenvandine :) [17:14] didrocks: it doesn't fail the build though :( [17:15] cyphermox: hum, are you sure? you have a diff and it doesn't? [17:15] cyphermox: it did a lot for me [17:15] with the env var? [17:15] yeah, I commented one out and bzr bd didn't fail [17:15] cyphermox: do you have an url handy? I can try it [17:16] i think that is intended to not fail the build [17:16] kenvandine: with 4, it should and it does here ;) [17:16] ok [17:16] (it's in my system env and not stripped by debuild) [17:17] what level shouldn't fail it? [17:17] 0 [17:17] i seem to recall folks setting that to 4 to short circuit the check [17:18] kenvandine: man dpkg-gensymbols [17:18] -c[0-4] [17:19] i guess i might have had the order backwards :) [17:19] yeah ;) [17:19] kenvandine: the merger always did export 0 [17:19] because I didn't wanted it to fail [17:19] as the packaging was separated [17:19] (it sedded beautifully the debian/rules file) [17:20] cyphermox: do you have a link of what you are trying so that I can give it a shot? [17:20] didrocks: lp:~mathieu-tl/indicator-messages/inline [17:20] thanks :) [17:20] comment out one symbol from libmessaging-menu0.symbols and run bzr bd [17:20] doing :) [17:21] cyphermox: oh [17:21] you need to export it [17:21] export DPKG_GENSYMBOLS_CHECK_LEVEL=4 [17:21] because it's a subprocess [17:21] (dpkg-gensymbols) [17:21] of course [17:21] I suck [17:21] :) [17:21] * cyphermox facepalm [17:21] no, you just got trapped :p [17:22] no, that's just being dumb, I know about this ;) [17:22] well, no worry anyway, I was just surprised that it didn't work :) [17:23] I confirm that bzr bd isn't happy after that! [17:23] well, I also was suprised ;) [17:23] of course that works now [17:23] well, the MR is updated [17:24] cyphermox: looking! [17:34] cyphermox: even my pbuilder is happy. Good work! :) [17:35] fginther: https://code.launchpad.net/~mathieu-tl/indicator-messages/inline/+merge/134100 is ready for inline packaging landing [17:38] alesage, I may need your help with ^^ indicator-messages MP [17:45] didrocks, fginther I confess that I'm surprised by this proposal, thought we resolved to leave indicators-stack packaging "out of line"; tedg and kenvandine wishing to review? [17:47] Also confused why you'd drop all the history of the other bazaar branch. [17:48] cyphermox, ^ [17:49] tedg: I'm not sure how I could keep it. It's not hugely relevant for the packaging branch though, because the history is in debian/changelog [17:49] or what branch history do you mean, actually? [17:49] cyphermox, It is, because debian/changelog doesn't really have information for things like bzr blame. It's really an incomplete history for user consumption. [17:50] no [17:50] debian/changelog contains the history of who changed what [17:50] cyphermox, I mean start with "bzr merge lp:~ubuntu-desktop/indicator-messages/ubuntu" instead of "cp" [17:50] cyphermox, not really, I edit that file all the time :-) [17:50] right, but when you edit it, you should have your name on top or on the trailer line [17:51] e.g. using dch [17:51] tedg: those branches don't have ancestry [17:51] cyphermox, And when I delete a revsion in the middle because it isn't relevant? [17:51] cyphermox, Yes, they do. They're properly build bzr build-deb branches. [17:51] what do you mean delete a revision? [17:51] Not some importer stuff. [17:52] cyphermox, Edit the file, select those lines. Hit delete. [17:52] you should never have to remove stuff from debian/changelog [17:52] oh wait [17:53] You do though in reality. Distro doesn't care about all the PPA trial version or anything else. [17:53] ubuntu-desktop/indicator-messages/ubuntu was a full branch, not a merge-mode branch, it possibly did have ancestry, but when I initially tried to merge it basically blew up in my face [17:53] tedg: but you could just as well include it [17:53] If you only look at it from the "one archive" perspective you don't, but that's a limited perspective. [17:55] anyway, whatever, I don't feel strongly for one way or the other. I don't think the history for that was very relevant [17:55] (because what we care about was already in changelog) [17:57] I would say all history is important, it's what defines us :-) [17:57] And, at a practical level. It makes your branch conflict with any other. [17:57] Because now you've created new file IDs [17:57] For the same files. [17:58] tedg: there are no same files [17:58] it's adding debian/ [17:58] that's really it [17:59] cyphermox, We have many packaging branches. Now all of those (which have a debian dir) conflict with yours. [17:59] just retesting, merging lp:~ubuntu-desktop/indicator-messages/ubuntu into lp:indicator-messages reverts a bunch of changes done upstream [17:59] tedg: what do you mean many packaging branches? [18:00] the goal is to take the packaging and fold it upstream, I'm not sure what else needs to be done. all the other branches should IMO just go [18:00] https://code.launchpad.net/~indicator-applet-developers/indicator-messages/ubuntu [18:00] https://code.launchpad.net/~indicator-applet-developers/indicator-messages/ubuntu.0.4 [18:00] https://code.launchpad.net/~indicator-applet-developers/indicator-messages/ubuntu.0.3 [18:00] https://code.launchpad.net/~ken-vandine/indicator-messages/lucid [18:00] https://code.launchpad.net/~indicator-applet-developers/indicator-messages/ubuntu.0.1 [18:00] https://code.launchpad.net/~indicator-applet-developers/indicator-messages/ubuntu.0.2 [18:01] All of those are comparable, because they use the same file IDs. [18:02] that's fine, but those should just go. they are still useful historically prior to a possible merge of my work, but past that the "upstream" packaging is what we want to use [18:02] anyway, let's bring that up to didrocks to decide [18:02] * cyphermox will head back to NM for the time being [18:03] also, if you know how to cleanly just merge the *right* packaging branch, which should be ~ubuntu-desktop/indicator-messages/ubuntu into lp:indicator-messages (for example), then please teach me :) [18:04] (by cleanly I mean without messing around with all the non-debian/ changes we clearly don't want) [18:05] cyphermox, They're probably there because of distro patching. You can just bzr revert all of those. [18:05] cyphermox, Then you keep with the upstream branch. [18:05] Well, I guess I'm not allowed to use the term "upstream" anymore. [18:06] well, yes you are :) [18:06] "The version with the changelog that no one edits and is out of date" [18:06] tedg: that's what we want to change [18:06] bzr log > debian/changelog [18:06] tedg: or actually, that's what *will* change, because that will be the canonical changelog for the projet [18:06] oh god no [18:07] No, it won't be. The Bazaar history always will be. [18:07] It's a nice try, but a failure waiting to happen :-) [18:07] there's a disconnect here [18:07] changelog is meant for the packaging changes, not upstream changes [18:07] Exactly, which is why they shouldn't be in the same branch. [18:07] (with the possible exception of key new features) [18:08] tedg: talk to didrocks, there were more than one discussions about this stuff at UDS, and the net result was to fold in debian/ to upstream packages to get easier daily uploads to the archive and help you guys with feedback [18:09] Not something we asked for or felt we needed. But yes, didrocks decided to do that. [18:09] well, maybe not for indicators so much, but quick feedback on changes was something that unity would win on [18:10] I'm saying this, but I wasn't in *all* of the sessions about this :/ [18:10] No, not really. Because what will happen is the devs will stop committing to trunk. They don't want quick feedback from users, they want to be able to discuss things amongst themselves first. [18:11] So "trunk" is the new packaging branch. And "not trunk" is where work gets done. [18:11] not quite [18:11] trunk should be where stable stuff lands, and not trunk for unstable, possibly broken crack :) [18:11] e.g. trunk always builds and has as few regressions as possible [18:12] Sure, kinda like "releases" were before. [18:12] yeah [18:12] So anytime where a release would be made before, that's now a merge to "trunk" [18:12] with the difference of releasing just about every day to the archive [18:12] No, it'll only release when something is added, it won't get commits everyday. [18:13] There's no reason for devs to want to commit to it. You just get yelled at by users. [18:13] tedg: basically, it will be the same CI as usual, except when this pass unit tests and some extra testing it will get automatically in archive [18:13] Kinda like "releases" in the past. [18:13] tedg: trunk it's meant for new crack until it's stabilized though, that's what was happening because (maybe) and why people were complaining [18:14] tedg: let's punt this to didrocks. I'm just the muscles for this one ;) [18:15] can't believe we're in such apparent disagreement right now though, I would have thought it would have been already discussed with you and more or less agreed to already, I'll ask him what's up [18:16] fginther: so you're holding off on that merge for now, right? :) [18:16] one more day won't hurt === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === salem_ is now known as _salem [18:41] cyphermox, yes, holding off for now === rsalveti_ is now known as rsalveti [19:36] hi all! [19:38] I just tried to compile unity according to the manual on unity.ubuntu.com, however, cmake produces an error even before compilation starts. Maybe this manual needs fixing? I'm using ubuntu 12.04. [19:50] cmake complains "package 'unity-protocol-private' not found" [19:50] charles, you need to compile/install libunity or grab the stagging ppa [19:50] charles, opps! wrong person [19:50] charon__, ^ [19:51] :) [19:52] libunity-dev is installed. does this mean, the version is not compatible with the unity trunk? [19:53] charon__, yes, the unity-protocol-private was added later...(im not sure when), but it is in trunk libunity [19:54] what exactly is considered to be a package btw? is it some form of a c++ class? [19:54] umm im not sure what you are asking [19:54] the cmake script also complained that package zeitgeist was not available, so I installed libzeitgeist-dev and that error went away [19:55] * bschaefer also doesn't know much about packaging [19:55] I mean, obviously the package is part of libunity. Is this an API or what? [19:56] sorry for these questions, but i'm _really_ new to unity. [19:57] before also compiling libunity, maybe I should try to build unity 5.x, which is part of ubuntu 12.04. [19:57] hmm I would think it is just part of it [19:58] that should work for you [19:58] bzr branch lp:unity/5.0 [19:58] thanks for that! [19:59] np! let me know if you run into any other compiling problems [20:00] still, the website (unity.ubuntu.com) needs fixing as it just doesn't work anymore. The manual states that it is meant for precise, which I'm using. [20:01] hmm I would think the current state of building unity would be with the current version... [20:01] * bschaefer goes to look at the site [20:03] compiling unity 5.0 seems to work [20:03] well you wont get trunk unity, you'll just get unity 5.0 [20:04] that's fine. I need to fix a bug in unity 5.x ;) [20:04] perfect then :) [20:23] Hmm, not a good idea to run the freshly compiled unity with unity --replace. My display just got crazy with many graphics errors. [20:26] what is a good workflow for testing a freshly compiled unity? [20:27] 'unity' should work or using the standalone files [20:27] unity/build/dash/dash [20:27] (without crashing the running unity from the repository) [20:27] well running 'unity' kills compiz, then restarts compiz [20:28] what errors does it give you when you run unity? [20:29] Is it a good idea to use another user? For this user, a second instance of lightdm is started on alt-f8? [20:29] I then wouldn't care if something crashes. [20:29] hmm no, you should be fine just running 'unity' [20:29] the display becomes _very_ colored with a lot of pixel garbage. [20:30] so i can't say what it says ;) [20:30] try running 'unity' in a tty [20:30] alt-f1 [20:30] ok. [20:30] then going back to f7 [20:31] ctrl+alt... [20:32] I'm not a linux newbie ;) [20:32] :), the ... are for me forgetting the ctrl part haha [20:33] hmm, could be that it is working now. I used "unity-env" to get my staging branch, then "unity --replace" [20:33] because what should happen. Compiz is killed, then restarted with the unity you built...which then it should go and actually restart the unitshell plugin [20:33] hmm [20:34] and if it fails it would say Error to load unityshell...but im not sure what you are seeing, or if there are any errors [20:35] it now started without errors [20:35] I just have to check that it is the compiled binary from me and not the one from the repository. [20:35]