[06:34] highvoltage: the schema is org.compiz.unityshell, but it is relocatable (to various profiles). I still don't eat gsettings for breakfast so not immediately sure how the unity profile default should be overridden [06:34] I guess one could try just [org.compiz.unityshell] in an .override file [06:36] check out the dh_installgsettings manpage. === mechanobot is now known as amithkk [08:33] mmrazik: any idea why latest ps-unity-autopilot-release-testing failed? [08:36] * mmrazik is looking [08:38] sil2100: hey, quick approval: https://code.launchpad.net/~didrocks/nux/common-any/+merge/142647 ? [08:39] didrocks: there is _usr_bin_compiz.1000.crash in /var/crash [08:39] so I guess a compiz crash [08:39] mmrazik: during the install? [08:39] going to look via kcm [08:39] ok :) [08:39] didrocks: install seems to be completed [08:39] it doesn't seem it even launched one test, right? [08:40] and having that on all configs, I wonder what's happening [08:40] correct. The test started but the "check unity is on" failed [08:40] didrocks: this is the AP log: http://pastebin.ubuntu.com/1516238/ [08:40] mmrazik: let me upgrade from the ppa [08:40] usually it says something like "Starting test ..." [08:40] ok [08:41] let me upgrade and starts a guest session, one sec [08:44] mmrazik: ok, I confirm, unity trunk is broken [08:44] sil2100: popey: Mirv: can any of you confirm this? [08:45] I think we'll have to look for the guilty commit :/ [08:45] mmrazik: meanwhile, can you try to do what we discussed yesterday for detecting when we install more than what we should? do you need help for that? [08:47] didrocks: well.. Help would be appreciated. I won't be able to have a look on it this morning. Ideally it would be best to do the testing in the preseed and quit the installation right away. I just don't know if there is a way from the preseed to kill the install in a way UTAH will notice the whole thing terribly failed [08:47] mmrazik: can you just try right now to exit 1 in the late_command? [08:47] mmrazik: just to ensure it aborts the install [08:47] at least, I will be able to build on that then :) [08:48] mmrazik: doing that will be really helpful [08:49] mmrazik: you can use the indicator test if needed for it [08:49] didrocks: ok [08:52] hmm [08:55] didrocks: confirmed [08:55] hmm, I don't have those in use [08:55] ok, seems confirmed enough [08:56] i get a compiz crash [08:58] Trying [08:59] Since currently I have some unity problems here in overall [09:00] urgh, a local build is working… [09:03] I confirm, unity from staging seems broken [09:03] sil2100: you are using staging or daily? [09:04] didrocks: this time I used staging to get the latest unity trunk [09:04] * popey is on daily, not staging [09:04] But I see anyway unity didn't have any new risky commits, hm [09:04] I don't understand, local build with latest unity -> working [09:07] hm, I see that on my guest session, compiz decied that my system needs to use software rendering [09:09] I don't see anything in nux leading to an ABI break [09:09] duflu: anything in compiz leading to an ABI break? [09:09] Not sure if this was related, but unity started working after I installed compiz from staging [09:09] the opengl thingy? [09:09] So this smells like ABI breakage to me? [09:09] yep [09:09] THe recent compiz commit seems risky indeed [09:10] let me first rebuild unity in the daily build ppa [09:10] didrocks: No core ABI breaks. OpenGL ABI changed yesterday but that code is unused by Unity or any plugin outside of opengl itself [09:10] Since the opengl plugin ABI got bumped [09:10] So was not really an ABI bump [09:10] duflu: yeah, I saw you told that on the merge [09:10] duflu: however, right now, unity is crashing at startup, the 2 nux commits seem fine [09:10] duflu: and rebuilding locally with latest stack is working [09:10] let me try to rebuild it in the ppa [09:11] didrocks: Hmm, let me see if Unity might use the modified class indirectly by another class [09:11] Latest unity works with latest compiz in staging [09:11] duflu: this can be some kind of this tricky case [09:12] duflu: seb128 confirms that only installing the new compiz since yesterday is breaking unity [09:12] so yeah, it's using it indirectly [09:13] didrocks: Nope the modified class is only used privately inside compiz opengl plugin. That won't be the problem [09:13] well, it seems that empirical tests prooves that there is some kind of breakage for unity in some way :) [09:14] popey: sil2100: unity rebuild launched, I hope that we can have autopilot test results afterwards [09:14] didrocks: Only the size/layout of PrivateGLScreen could have changed. Nothing else [09:14] duflu: maybe it's used in some way by unity, indirectly? or nux? [09:14] I doubt on nux though, it doesn't bring compiz pieces IIRC [09:15] didrocks: No it's properly private to compiz AFAICT [09:15] duflu: well, something is guilty for sure in the recent compiz changes, as the tests seb128 did show [09:15] didrocks: [09:15] taking yesterday ppa state [09:15] \o/ [09:15] updating compiz compiz-core compiz-dev compiz-gnome compiz-plugins-default [09:15] libcompizconfig0 libcompizconfig0-dev libdecoration0 libdecoration0-de [09:15] and you have the issue [09:16] Well, I doubt nux as well, since I didn't install new nux packages [09:16] sil2100: during the rebuild, two things, not sure if you saw my nux MP above to change -common from arch: all to arch: any? [09:16] didrocks: OK, but what revision was working last? [09:16] sil2100: second one, I saw that brandon has committed a fix for the 8 new tests failing, what's still on the map? [09:16] didrocks: yes, but Alan was faster with approving ;) [09:16] oh? he stole karma!!! :) [09:17] duflu, the issue is in that diff probably: https://launchpadlibrarian.net/128073372/compiz_1%3A0.9.9~daily13.01.09-0ubuntu1_1%3A0.9.9~daily13.01.10-0ubuntu1.diff.gz [09:17] duflu: didn't do a bisect, but I can give you with what version it was built against yesterday [09:17] didrocks, ^ [09:17] duflu, that's the diff between the daily snapshots yesterday (which was working) and today [09:17] didrocks: Yeah I just reviewed all those :P [09:17] duflu: so, between rev 3549 and 3552 [09:18] didrocks: if our predictions are correct, with Brandon's fix and all the others, we should have no failing tests for the indicators [09:18] didrocks: OK, looks like if (!CompPlugin::checkPluginABI("opengl", COMPIZ_OPENGL_ABI)) [09:18] At least that's the expectation we would wish to confirm :D [09:19] sil2100: \o/ let's trust the mayas then! [09:19] The ABI was not broken, but incrementing the macro prematurely broke Unity :( [09:19] Damn you ABI versions [09:19] duflu: this is in unity? [09:19] this check? [09:19] didrocks: Yes in unityshell. Looks like the problem [09:20] I thought ABIs were compared >= but they're compared with == [09:20] didrocks: So either rebuild Unity or revert the COMPIZ_OPENGL_ABI increment. The increment was wrong [09:21] duflu: argh, the virtual package is juste creating on the core abi version [09:21] didrocks: I know. Different library, different ABI :P [09:21] duflu: as you wish, maybe reverting the increment? [09:22] didrocks: I will push it back to 6 right now if you like. Need review? [09:22] duflu: no, please autoapprove :) [09:22] thanks for digging into it [09:23] didrocks: It's the only explanation. Not proven yet though [09:23] duflu: I feel you're right, if you are sure the changed struct is not leaked [09:24] didrocks: Pushed to lp:compiz in a quick and evil way. [09:24] duflu: evil is fine sometimes :) [09:25] it's another argument to autobump the build-dep version as part of the daily process [09:25] I really wonder, nobody answered on that on the unity-dev ML [09:25] but I feel we'll have to [09:26] didrocks: Technically it is behaving correctly. Checks the opengl plugin for compatibility and bails if it's not reporting itself as compatible [09:26] But incompatible is bad. Quite bad [09:27] duflu: yeah, I guess if this kind of breakage (justified or not) without bump build-dep is happening too much, the only way will be this autobumping build-dep on all components parts of the stack [09:27] duflu: it's technically incorrect, but practically… [09:29] didrocks: I think ted was partially right. Downstream projects like Unity should not be getting new code while that new code still needs to change so often. But your argument for daily builds is at least as strong [09:29] I would like to call the ABI "0.9.9" when 0.9.9.0 is released and declare it fixed then [09:29] duflu: well, after 3 years, seeing that the code still needs to change so often means that something is not working properly :) [09:30] I agree on young-incubating project that this doesn't work [09:30] didrocks: Yes there are bugs because it's a massive codebase and almost no developers :( [09:30] but after a public official release, it should be good [09:30] yep [09:31] But it's an order of magnitude fewer new bugs each week than a year ago. So lots is "working properly" [09:32] so we should ought to expect trunk to always work, and new incubating things in a separate "per feature" branch [09:32] and once properly cooked, merged into trunk [09:33] It's anyway much better than before [09:35] Since we're able to use staging/daily normally for a longer time, without any big breakages [09:35] sil2100: oh, not related but the prev/next issues are fixed? I didn't see a merge for this [09:35] as you couldn't figure out why it was still broken yesterday [09:37] didrocks: There was nothing I could have done to avoid this. The failing function is one I had never looked at before (like 90% of compiz) [09:37] Failures happen and we fix them [09:38] duflu: yeah, but we can mitigate this can of failure by forcing everytime building against latest build-dep [09:38] even if it's unecessary [09:38] and I can automate that [09:38] s/can/kind/ [09:39] I just need people thought on this to know if they think it's a good idea or not :) [09:39] and what the eventual drawbacks that I missed out (I can only see for backports, that we don't support, at least, when the stack is partial) [09:39] didrocks: So when do you stop forcing it? Release candidates? [09:39] duflu: even not [09:39] well, SRUs maybe [09:40] but otherwise, as we copy from the daily build ppa to the archive [09:40] didrocks: It certainly has to freeze by release. You need a fixed ABI then :) [09:40] duflu: well, it's not a card for "break ABI whenever you want" :) [09:40] it's just a technical solution to avoid getting those issues revealed [09:41] Am I the only one suffering from a broken raring desktop since yesterday night ? [09:42] MCR: using staging? [09:42] yep [09:42] MCR: backlog the discussion ^ [09:42] MCR: and so it's not raring being broken, it's the ppa :) [09:42] I was not sure what exactly caused it yet [09:43] Will it be fixed soon ? [09:43] Heh. And I only stopped using the PPA yesterday (just reinstalled raring) [09:43] MCR: just a rebuild of unity is fixing it [09:43] or revert to a previous compiz version from the ppa :) [09:44] didrocks: Since I hacked compiz you only need to rebuild that really [09:44] (I am on Mint 9 [my failsafe sys] and I want back ;)) [09:44] MCR: well, revert or rebuild compiz :) [09:44] didrocks: Yeah I will have to increment Unity's build-deps even if plugin ABIs change in future [09:44] No PPA fix ? [09:45] That's a new one [09:45] MCR: maybe, but once we'll get a new merge in process, not sure when it happens [09:45] ok, thx [09:45] MCR: as outlined in the ppa description, it's not supported and ensure to work everytime :) [09:45] yeah, I am not blaming anyone [09:45] I just was not sure if it was known already [09:47] MCR: when unity will be delivered everyday to raring, you won't need the ppa anymore :) [09:47] :) [09:49] didrocks: well, hm, ok, got confused right now [09:49] hum? [09:49] didrocks: so exit 1 in preseed does seem to exit the installation. But now utah waits for it to finish (trying to ssh) and it will take some time to timeout [09:49] Let me re-check something then [09:50] mmrazik: ok, I have another idea, can you just copy the list of additional package to install and we do that as the first test which can aborts, like the one you have to detect unity? [09:51] mmrazik: so I'll give you a script to install those eventual new packages, I just need that store the list of packages somewhere in the installed system [09:51] didrocks: sure but its exactly that sort of hacking I was trying to avoid [09:51] mmrazik: well, it seems we don't have better solution right now [09:51] and no time for refactoring all this preseed stuff [09:52] didrocks: ok [09:52] didrocks: since as you know, there was a lot of confusion yesterday on which tests are up-to-date and which not [09:52] sil2100: ah, I think those were still valid [09:52] sil2100: can you verify? [09:53] mmrazik: just tell me where you put this list of package (if empty, nothing else to install), I'll then propose a MP to your branch [09:54] sil2100: The manual tests are also heavily outdated, one refers to the update-manager and its windows, which have completely changed for example [09:54] didrocks: since, for instance, in http://10.97.0.1:8080/job/ps-unity-autopilot-release-testing/23/#showFailuresLink (which was ran on a newer unity) didn't have prev/next failing [09:54] didrocks: lets put it in into /home/jenkins/install_packages (--install-packages is the switch in the customize preseed command) [09:54] MCR: hm, yes, I think we'd need to remove those in overall [09:54] sil2100: ok, let's see with the new build then [09:54] didrocks: or no...give me a sec [09:55] mmrazik: that's the list of package I have to install, right? [09:55] didrocks: I'll put the following for indicators there: "bamfdaemon indicator-datetime indicator-messages indicator-application libindicator7 indicator-sound libmessaging-menu0 appmenu-gtk indicator-printers indicator-power appmenu-qt appmenu-gtk3 gir1.2-messagingmenu-1.0 indicator-appmenu libindicator3-7 libbamf3-1 libsync-menu1 indicator-applet-complete libido3-0.1-0 gir1.2-syncmenu-0.1 " [09:55] which is the jenkins parameter [09:56] yep :) [09:56] didrocks: and yep, I'll put it into /home/jenkins/install_packages [09:56] Unity as well! Add unity ;) [09:56] sil2100: I wanted to revisit them, run them, report eventual bugs and update them - but for some (like the one I mentioned above) finding replacement tests is not easy... [09:56] mmrazik: oh, but the user don't have sudo right, isn't it? [09:57] MCR: I think what we need to do is browse through the manual tests and check what tests are already as autopilot tests and those that are not, but are still valid, simply turning into AP [09:57] didrocks: If you need it I can add it to sudoers in preseed [09:57] mmrazik: or what we can do is create those two files [09:57] MCR: since we decided we don't want any manual-tests anymore [09:57] MCR: the idea is to have everything automated [09:57] mmrazik: like: /home/jenkins/install_packages and /home/jenkins/installed_packages [09:57] /home/jenkins/installed_packages beeing the output of apt-get install during the preseed [09:58] sil2100: Yes, gotta look @ autopilot, but I am not sure if all things can be automated... [09:58] mmrazik: then, the script will only test the logic of this [09:58] mmrazik: and exit if something is wrong [09:58] wdyt? [09:58] didrocks: ok [09:59] sil2100: So no more nice-testhouse ? [09:59] MCR: autopilot is really nice, and indeed - visual changes can't really be testable by autopilot, but those we anyway don't really test [09:59] MCR: I think testing is still needed - remember that we're not completely automated for precise and quantal ;) [09:59] didrocks: did you already branch the ~autopilot/unity/utah-jenkins branch? [10:00] And, checkbox-tests, which check overall system integration, are still manual [10:00] if so, can you please discard and branch again? Not proud what I just did there but I changed it. [10:00] sil2100: I seem to be the master in finding and being affected by Unity bugs noone else is suffering from :P [10:00] mmrazik: not yet, just creating the parsing script right now [10:00] mmrazik: ok, will do :) [10:04] MCR: ;p [10:12] didrocks: can I kill ps-unity-autopilot-release-testing? [10:12] or is it actually something you need? [10:12] mmrazik: it's needed [10:12] ok [10:12] mmrazik: that's what was prevented by the ABI break before [10:12] didrocks: I think the files should be there. The net (queued) indicators job will confirm [10:13] s/net/next/ [10:13] mmrazik: sweet! did you cat them? [10:13] so that we can see we have the expected content, for debugging :) [10:13] didrocks: http://pastebin.ubuntu.com/1516437/ [10:14] "unity indicator hud" are just 3 random packages (which don't even exist) [10:14] mmrazik: right, I just mean cat the /home/jenkins/installed_packages for the first weeks [10:14] mmrazik: so that if my script don't have the proper content, we can debug it [10:15] or I can do it in my scripts I guess [10:15] didrocks: cating wouldn't help -- utah is not stdout friendly :-/ need to store them as jenkins artifacts. [10:15] ah :/ [10:15] ok [10:15] didrocks: lets store them in /home/jenkins/results/artifacts [10:16] mmrazik: remember they are optional though [10:16] mmrazik: like with the "whole ppa" preseed, they are not here [10:16] didrocks: after the job ends we are scp-ing the whole results dir and storing it as artifacts [10:16] ok, it's not file by file then [10:16] didrocks: nope === mmrazik is now known as mmrazik|lunch [10:43] mmrazik|lunch, could you look at why https://code.launchpad.net/~mhr3/libunity/fix-nested-previews/+merge/142538 keeps failing please? [10:43] stuck xvfb or something? [11:01] mmrazik|lunch: rev 170 and 171. Can you give it a look and if good, will worth testing that it indeed aborts the tests :) [11:13] hey guys [11:14] I want to hack on unity on my local system [11:14] i have a launchapd Id and all === mmrazik|lunch is now known as mmrazik [11:14] I have cloned the unity repository and have been going through the doccs [11:15] can someone explain what upstream merge means > [11:15] mhr3: we had this recently with libdbusmenu. xvfb-run is trying to run the X on a specified display :99. If you are building on amd64 and i386 on the same machine then only one of the instances will work and the other fail to start [11:15] mhr3: the solution is to run "xvfb-run -a" [11:16] solancer: it IMHO means merging your changes back to lp:unity (but I'm lacking some context) [11:17] mmrazik, oh I see [11:17] mmrazik, didn't know the merger is so awesome now that it can run both 32 and 64bit builds at the same time [11:18] anyway thanks [11:18] mmrazik, so I have two repos cloned from launchpad with me [11:18] mmrazik, unity and unity revamped [11:18] mhr3: its there for months [11:19] mmrazik, if I make changes to the unity repo and push it to my personal PPA [11:20] mmrazik,and if unity has a new version release [11:20] mmrazik, would have to do something extra to keep up with the releases > [11:21] mmrazik, then the machine got faster or something :) === _salem is now known as salem_ [11:22] solancer: yes. You would need to merge the upstream (lp:unity) back to your own branch [11:23] solancer: usually something like bzr merge lp:unity in your working dir [11:23] mmrazik, cool [11:23] didrocks: the changes look sane. I would prefer not to modify the other preseed files but it shouldn't hurt either [11:23] mmrazik, and 1 more question [11:23] (i.e. only base-preseed needs to be modified) [11:24] mmrazik: just for consistency as we run it and it will exit with 0 [11:24] solancer: sure. Shoot. [11:24] but as you prefer :) [11:24] mmrazik: will this be picked automatically in the indicator run? [11:24] didrocks: its already there... lets keep it [11:24] ok [11:24] mmrazik, the cloned repo's name is unity and mine is unity-dodge [11:24] didrocks: not sure. let me kill it and start again [11:24] mmrazik: ok :) [11:25] sil2100: one hud test fail remaining! just one! :) [11:25] ! [11:25] didrocks: which one? ;) [11:25] sil2100: seems we have the same with the dash [11:25] unity.tests.test_hud.HudBehaviorTests.test_closes_then_focuses_window_on_mouse_down [11:25] unity.tests.test_dash.DashRevealTests.test_closes_then_focuses_window_on_mouse_down is failing as well [11:25] I bet same cause [11:25] mmrazik, shou ld I change the name of the cloned repo or I can jus start making changes to it and push it to my PPA [11:26] Ok, let me see that then! [11:26] solancer: you have the repo on your HDD? It doesn't really matter what is the name. [11:26] sil2100: look at jenkins directly [11:26] sil2100: the public instance is broken [11:26] mmrazik, yep I have it on my HDD [11:26] job/ps-unity-autopilot-release-testing/label=autopilot-nvidia/lastCompletedBuild/testReport/ [11:27] solancer: I would also sugest to push the repo somewhere to launchpad so you have a backup... not sure what is your launchpad ID but something like bzr push lp:~solancer/unity/my-branch-name [11:27] solancer: but you don't have to do it [11:27] sil2100: same failure on intel at least [11:27] solancer: so nothing needed. You can start make changes and then dput into a ppa [11:27] mmrazik, cool i'll start hacking then [11:27] few minutes for ATI :) [11:34] sil2100: and ati as well, so reproduceable everywhere :) [11:51] mmrazik: ok, the build failed, which artefact did you use to see that it didn't run? [11:52] didrocks: mhm... there is some utah stack trace in the job output. The files were apparently not copied back to jenkins [11:53] didrocks: so no artifacts :-/ [11:53] looks like some utf issue [11:53] mmrazik: so, this time, it failed due to UTAH? [11:53] but I wonder where [11:53] didrocks: the stacktrace comes from this command: [11:53] utah --install-type desktop -r /tmp/master.run [11:54] mmrazik: same for nvidia btw [11:54] nvidia/intel [11:55] mmrazik: are you tracking it? I'm not sure to know enough about UTAH and the guys behind it [11:56] didrocks: me neither. But trying to look into source code [11:56] the stack is only in the logging module :/ [11:56] yeah... just realized that [12:01] hm hm [12:08] mmrazik: any progress? talked on #qa? (not there, so didn't see) [12:08] I tried to export a locale and re-run the test [12:09] didrocks: I tried to reproduce by running the utah command on the host but didn't observe the stack trace [12:09] mmrazik: should we just retry? [12:09] weird that it failed on the 3 configs though [12:09] didrocks: yes. The job is already running. [12:09] ok [12:09] didrocks: with export LANG=en_US.utf8 [12:10] ok, let's see ;) [12:10] its just a wild guess [12:12] So, what I noticed [12:13] hm, autopilot in the jenkins unity tests uses a strange keybinding for maximizing the window - it seems invalid [12:14] Since in compiz we're patching through patches it to Ctrl+Super+Up, while it's using the old compiz one Super+Up [12:14] And it seems not to maximize the window then [12:14] That's why those 2 tests fail - now I need to find out why he has the keybinding set to Super+Up and why then it doesn't work [12:15] sil2100: good catch! :) [12:18] sil2100: 10_ubuntu-settings.gschema.override:maximize = ['Up','Up','KP_5'] [12:18] sil2100: I think it's the bug that smspillaz knows about [12:19] he has a fix I guess, but don't want to push it without tests and no motivation to write the tests [12:19] didrocks: what's the problem here? So it's a real regression then? [12:20] sil2100: well, only on this machine, and some others, the "integrated settings" are not overwritting the integrated key on first launch [12:20] I think I'll just update to only have 'Up' by default [12:20] a pity, but well… [12:21] * sil2100 sighs [12:21] Ok [12:21] sil2100: don't we have the same issue we show desktop btw? [12:21] sil2100: do you know some tests using it and failing? [12:22] hm, let me see, maybe indeed we're also getting hit by that - usually switcher tests are usign show desktop [12:28] sil2100: ok, I've uploaded ubuntu-settings in the ppa, once built, I'll relaunch the tests [12:29] mmrazik: how to interpret the nvidia autopilot indicator result? [12:30] didrocks: its the same stack trace, isn't it? [12:30] didrocks: build #55? [12:31] didrocks: thanks! [12:31] * sil2100 goes for lunch [12:31] mmrazik: there are some artefacts, isn't it? [12:31] oh.. right [12:31] so not sure if it's exactly the same issue [12:31] was my script launched already? [12:31] not sure where to see the logs :) [12:33] didrocks: your script has wrong paths. I moved the files into /home/jenkins/results/artifacts [12:34] mmrazik: ah, you didn't tell me :) but is the crash before it's launched or the utf8 issue is because of the script itself? [12:35] didrocks: I _think_ your script was not started [12:37] argh.. this preseed stuff debugging is a nightmare [12:37] anyone good with unity-2d ? wrt https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1096954 [12:38] Launchpad bug 1096954 in unity (Ubuntu Precise) " Enabling Xinerama causes Unity Panel/Dash to become all black" [Medium,Confirmed] [12:38] mmrazik: do you think it's due to the preseed? it's weird that we can reliably crash it now [12:38] didrocks: I don't know but the stacktrace in logs is something I'm worried mostly about [12:39] as it might very well mean the whole utah testcase just wasn't started [12:39] yeah [12:39] giving up. asking on #qa [12:39] * didrocks joins === MacSlow is now known as MacSlow|lunch === MacSlow|lunch is now known as MacSlow === mmrazik is now known as mmrazik|afk === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === mmrazik|afk is now known as mmrazik [14:39] sil2100: latest result, job ps-indicators-autopilot-release-testing, rev 57 [14:39] sil2100: still prev/next failing [14:40] (both on nvidia, only prev on ati/intel) [14:40] mterry: FYI ^ [14:40] :-/ [14:41] I haven't read code branches today. Does that the tested code include a fix for the alt+f10 problem? [14:41] mterry: I didn't see it flying [14:41] but maybe I missed it, with all the autopilot issues today… [14:42] OK, good. So we may have a path towards completion! :) [14:42] hoping so :) [14:42] mterry: you're looking after it? maybe check with sil2100 and brandon [14:43] k [14:46] thanks! :) [14:59] mterry: FYI, that's the latest blocker before enabling the daily release for unity \o/ [15:00] I would love to have the first daily release tomorrow :) [15:00] Friday, what can happen? :) [15:01] heh [15:02] mterry: also, sorry to jump on you so early, but did you get anything on the indicator test during build? trying to gather some info as I won't be really available next week :) [15:02] libappindicator? [15:03] right, and indicator-session [15:03] IIRC [15:03] No, I thought I had a promising fix, and it might have fixed part of it, but it wasn't enough. Still investigating [15:03] ok ;) [15:03] cyphermox, I thought you had indicator-session well understood? Or a possible fix or something? [15:04] I tried something, it failed [15:04] indicator-session is borken as much as libappindicator -- the test reproducibly fails in a PPA no matter what I change [15:05] I think it's due to some dependency missing in the build -- and then it should probably be explicitly listed in the binary package deps. [15:05] (once we find out what the hell it is) [15:05] what test is that in indicator-session? [15:05] TestCanStartService [15:05]