=== salem_ is now known as _salem [03:18] bregma: do you know what the status of those reviews I had up were ? They seem to just be sitting there ... [03:19] we've been discussing requirements for change to the Switcher [03:19] so I'll need to rewrite them again ? :( [03:19] maybe [03:19] argh [03:19] maybe I will just fork unity .... this is getting annoying [03:21] previous problems came from being in a hurry, we taking a moment to think long-term before the next wave of slip hits the fan [03:21] bregma: so one of the things I've learnt is that our short cycles make it impossible to "think things through" [03:21] by the time you've done all the thing its feature freeze [03:22] *thinking [03:24] well, that has to change or else there's a certain future and it isn't my idea of a successful one [03:24] * duflu remembers fondly the luxury of being able to go away and develop for months and months without interruption or short cycle requirements [03:24] bregma: good luck with that one [03:24] heh, yeah, I'll need it [03:25] bregma: the only way to survive in a situation like this is to embrace constant improvement over perfection [03:26] because I've seen it happen again and again. We have something that gets us 75% of where we want to go and then people spend forever nitpicking over the details to make it so that every change is "perfect" and then feature freeze happens and you go from 0% to 0% [03:27] examples: sheet style dialogs, mesh icons in the switcher, coverflow, the entire /unity/+activereviews [03:27] Isn't the problem the lack of people doing nitpicking? [03:28] no the problem is when nitpicking turns a review that should take 3 days into one that takes 13 weeks [03:29] short cycles are a problem, yes. But the best thing we can do is adapt rather than pretend that we don't have short cycles [03:30] well, there are plenty of problems across the spectrum, and there are ways to avoid those problems [03:31] I think pretending can be realistic. If something's not ready or people are not confident that it's ready then the next release is only 6 months away. That lines up with commercial software practice where the cycle is measured in years, not months. And it works but is incredibly frustrating to tell people "yeah it won't be released for a year or so" [03:32] duflu: the graveyard of bleeding baby deer that is the unity activereviews page begs to differ that this is an effective solution [03:36] smspillaz: I haven't got hold of David yet but do you still want to drop the netbook over? [03:37] duflu: maybe sometime today. When do you leave ? [03:39] smspillaz: A few hours after midnight on Sat morning :( [03:39] lovely [03:52] bregma: in any case ... let me know when you've finalized a design for the switcher that you want. I've got lots of work sitting there waiting that will really help you with where you want to go. its your teams choice as to whether or not engagement happens or it just sits there and does nothing [07:08] didrocks: it looks like the libdbusmenu tests are failing when both archs are scheduled to be built on the same builder host. If I try to execute 2 instances of xvfb-run at the same time one of it usually fails with the same error [07:08] * mmrazik is just reading the man page if it is possible to randomize the server # [07:09] mmrazik: oh, interesting, even if it's run in a pbuilder? === amithkk is now known as Guest39143 [07:09] so it's not multiprocess? [07:09] didrocks: only tried locally [07:09] ie no pbuilder [07:09] ah :) [07:09] but yeah, maybe it's what is happening [07:10] didrocks: there is xvfb-run -a [07:11] didrocks: shall I just create a separate MP for that to try it out (and eventually merge) ? [07:11] mmrazik: yeah, please do :) [07:11] mmrazik: we call it in debian/rules FYI [07:11] debian/rules:xvfb-run dh_auto_test --builddirectory=builddir/$* [07:11] didrocks: ack. [07:18] mhm... this is going to be difficult to test as the jobs were scheduled to be built on two different builder hosts [07:19] mmrazik: it was scheduled to be built on two different builder hosts? so the failure I just got is not linked to that, isn't it? [07:20] didrocks: hard to tell. in the last case when one of the arch failed it was building on the same host. [07:20] didrocks: my MP with xvfb-run -a is now being built on two different hosts [07:20] didrocks: as well as the last message in your MP (which passed) [07:21] so the hypothesis sill holds [07:21] mmrazik: ok, so let's try to get that merged in :) [07:21] mmrazik: if we can have that in 2 separate MP, it will be awesome [07:21] mmrazik: like, get yours merged [07:21] didrocks: https://code.launchpad.net/~mrazik/libdbusmenu/xvfb-run-a/+merge/142448 [07:21] and then, we can try again getting https://code.launchpad.net/~didrocks/libdbusmenu/bootstrap2/+merge/142446 merged [07:22] the CI job is running right now (but as I said -- on two different hosts so I expect it will pass) [07:22] approved, let's see how it goes :) [07:22] ack [07:22] at least, we'll have 2 MP [07:31] didrocks: so the autolanding job just started and both archs are building on the same jenkins slave [07:32] mmrazik: sweet, can't wait for the result! :) [07:32] the ci passed [07:32] let's see autolanding [07:37] didrocks: it probably was the issue because now I see in the logs that one of the server is running on :99 while the other on :100 [07:39] mmrazik: excellent! so it's something that is leaking through the bindmount of pbuilder [07:39] I didn't thought about it [07:39] think* [07:40] mmrazik: let's continue crossing fingers, that would rock :) [07:40] didrocks: not sure if leaking. I think this is by design. Even in chroot certain resources like sockets I shared (I think) [07:40] mmrazik: right, I meant leaking like "not being isolated" [07:40] but there are good reasons for that, I can see [07:40] I thought though this was done in /tmp [07:45] didrocks: mhm.. the autolanding tests passed but the merge failed with the chk root keys error :-/ [07:51] mmrazik: urgh, so you are getting the same issue? [07:52] you just bzr branch trunk, rihgt? [07:52] right* [07:52] didrocks: yes. And you bootstrap2 branch is going to have it too (I just failed to checkout it). [07:52] didrocks: yes [07:52] didrocks: I justr tried the reconcile think and will try to push to a different location in lp [07:52] mmrazik: ok, keep me posted… [07:52] mmrazik: at least, good news that it seems to have work :) [07:54] didrocks: no luck :-/ [07:55] no idea how to proceed with this : [07:56] let's go on #bzr maybe? [07:56] didrocks: wasn't francis already there? [07:57] mmrazik: he sent an email, but it was in the US time, we will maybe grab some european folks [08:22] mmrazik: do you mind rerunning the merge process? (for your branch first) [08:22] so that if we see other issues, we can debug with the bzr guys fast enough ;) [08:26] didrocks: just got merged: https://code.launchpad.net/~mrazik/libdbusmenu/xvfb-run-a/+merge/142448 [08:26] \o/ [08:27] mine mine mine now! :-) [08:29] didrocks: the jenkins job just started [08:29] mmrazik: refiling coffee meanwhile :) [08:42] mmrazik: and merged \o/ Thanks again :-) [08:43] great :) it only took a day or so :) [08:45] heh [08:49] didrocks: hi! [08:49] hey sil2100! how are you? [08:49] didrocks: the fix introduced by https://code.launchpad.net/~brandontschaefer/unity/skip-switcher-lazy-loading-timer/+merge/142396 should fix some of the indicator failures \o/ [08:50] Yesterday evening we found this one and analyzed as a possible reason for all those annoyances [08:50] sil2100: yeah, I saw that, I'm running an unity rebuild right now and then, will rerun the indicator ones [08:51] sil2100: I saw the discussion, it's awesome :) [08:51] sil2100: however, on your branch… I didn't see anything proposed on the autopilot side [08:51] so maybe worth to merge it meanwhile? [08:52] You mean, the fix for the test_mouse_changes_selected_hud_button I proposed yesterday? [08:53] yep [08:53] Not sure if we should change the default rate for all mouse movements [08:53] yeah, I wonder as well [08:53] so, that's why I think we should merge yours for now [08:53] and we can eventually remove that later on [08:53] Indeed I'll have to consult Thomi, but sometimes it's not necessary, and it would only slow down the tests [08:53] if autopilot changes it [08:53] wdyt? [08:53] Yea, I think so too [08:53] want me to approve drastically? [08:54] didrocks: please ;) Some free karma for you as well ;p ! [08:54] heh, here is a drastic approval! [08:55] sil2100: nice work! :-) [08:55] sil2100: do you know if you can still work on other remaining failures meanwhile I rerun a full test? [08:55] sil2100: and how did it go with mterry, was he able to setup his configuration fine? [09:01] didrocks: he went to eat lunch and do errands, I sent him instructions on how to run autopilot for indicators, but I didn't hear back from him [09:01] So I don't know [09:01] ok :) === mmrazik is now known as mmrazik|afk === mmrazik|afk is now known as mmrazik === cking_ is now known as cking === mmrazik is now known as mmrazik|afk === mmrazik|afk is now known as mmrazik === mmrazik is now known as mmrazik|afk === _salem is now known as salem_ === MacSlow is now known as MacSlow|lunch === francisco is now known as Guest79688 === mmrazik|afk is now known as mmrazik === gatox is now known as gatox_brb [12:17] sil2100: did you wait on the result or working on the next() prev() tests? [12:19] there are 8/9 hud tests failing from what I can see [12:20] didrocks: after Brandon's fix? [12:20] And my icon fix? [12:20] yeah, just without your "move slower the mouse" [12:20] huh [12:20] So the 4 tests I fixed by fixing the regression still fail? [12:20] Same for gedit_undo? [12:20] Doesn't make sense [12:21] https://jenkins.qa.ubuntu.com/job/ps-unity-autopilot-release-testing/label=autopilot-ati/lastCompletedBuild/testReport/ [12:21] https://jenkins.qa.ubuntu.com/job/ps-unity-autopilot-release-testing/label=autopilot-intel/lastCompletedBuild/testReport/ [12:21] https://jenkins.qa.ubuntu.com/job/ps-unity-autopilot-release-testing/label=autopilot-nvidia/lastCompletedBuild/testReport/ [12:21] there is not the gedit_undo, isn't it? [12:21] Oh, so it's not for the indicators? [12:21] we run hud tests as well, isn't it? [12:21] Ok, some other tests fail I see [12:22] yeah, only the hud ones (I rerun all the tests, as I was rebuilding unity) [12:22] so this is with all the fixes, but the slower mouse move [12:22] Yes, but the prev next and undo things stopped failing, some new failures appeared, hm [12:22] which don't impact those tests? [12:22] yeah [12:22] Ok, let me look in detail into this [12:23] thanks :) [12:25] didrocks, sil2100: Hi :) HUD in Unity trunk also has problems to show the correct icon, but overrides the correct icon with the first one all the time... [12:27] didrocks, sil2100: The icon from the first HUD line always overwrites all others, which is quite bad :( [12:29] hum, I can see in trunk always the right icon here [12:30] didrocks, sil2100: Also something with the blur gotta be done - the blur function is incredibly slow, especially with free drivers... [12:30] didrocks: ok, so, there is one HUD fix I will add now which I forgot to commit and push yesterday for fixing the focuses_window_on_mouse_down [12:30] MCR1: hmm, didn't notice that [12:30] With the HUD I mean [12:30] sil2100: Maybe it is MCR-specific then - strange though... [12:30] sil2100: oh oh nice! :) [12:31] didrocks: but those 8 new HUD failures I see for the first time ;p [12:31] sil2100: maybe we don't run them as part of the indicators tests, let me recheck. I just stumbled above them [12:32] sil2100: hum, we do run unity.tests.test_hud [12:32] so they should be run, isn't it? [12:33] ok, first getting your merge in and rebuilding unity :) [12:33] Right, so maybe latest unity trunk broke something? Since those never failed before === gatox_brb is now known as gatox [12:33] sil2100: yeah, maybe brandon's fix has this side effect of not hiding this bug :) [12:34] hehe\ [12:34] send the MP once ready! :) [12:35] When I open the Dash or HUD here, running video starts to stutter, the blur kills my framerate completely (on quite fast hardware ATI HD 5750) - this does not happen with fglrx, but with free gallium radeon driver... [12:41] sil2100: I'm about to leave for some exercice, I would like just to have your merge in the queue before you have it handy :) [12:44] didrocks: ok, pushing ;) [12:51] mmrazik: hey, how can I see which packages are installed in jenkins-qa/job/ps-indicators-autopilot-release-testing/46/label=autopilot-intel/ ? [12:51] mmrazik: even if only the indicators should be installed, I've a similar result than when using the whole ppa [12:52] so I wonder if it doesn't take unity from the ppa [12:52] sil2100: any luck btw? :) [12:53] didrocks: #46 is still running you will be able to see it only after it has finished [12:53] didrocks: here it is for #45: https://jenkins.qa.ubuntu.com/job/ps-indicators-autopilot-release-testing/45/label=autopilot-ati/artifact/results/artifacts/machine-config/dpkg-list.log/*view*/ [12:53] you need to go to the machine and then there are build artifacts [12:53] and there its in results/artifactrs/machine-config dir [12:54] didrocks: https://bugs.launchpad.net/unity-2d/+bug/1060262 <- it's released? Where? [12:54] Launchpad bug 1060262 in unity-2d "Unity-2D SRU-1 needs releasing" [Medium,Fix released] [12:54] mmrazik: look at job/ps-indicators-autopilot-release-testing/46/label=autopilot-intel/artifact/results/artifacts/machine-config/dpkg-list.log [12:54] It's not released... [12:54] mmrazik: it has unity from the ppa where it shouldn't [12:55] sil2100: I based on the date, please revert if I've mistaken [12:55] I specifically pushed it back to the queue to get it released again, since last time it got rejected :< [12:55] mmrazik: see ii libunity-core-6.0-5 6.12.0daily13.01.09.1-0ubuntu1 i386 Core library for the Unity interface. [12:55] Now it'll land in the sponsoring queue from the beginning again :< [12:55] sil2100: well, juts revert to fix committed [12:55] sil2100: that doesn't change a thing :) [12:56] ;) [12:58] sil2100: so, at least, with that, we have the confirmation that the tests for hud fails now [12:59] sil2100: btw, you know that you have the ogv? [12:59] sil2100: for the test failing [12:59] didrocks: yes, I watch it every time - I'm using apview ;) [12:59] A really useful tool btw.! [12:59] didrocks: weird... I'm just looking at the preseed and I don't see anything wrong there. dist-upgrade happens before adding the ppa [12:59] sil2100: apview? [13:00] didrocks: is it possible that something like bamfdaemon pulls all that in as a dependency? [13:00] ok [13:00] bamf is probably a bad example... [13:00] mmrazik: no, it's not, it's a good one [13:00] so bamf broke its abi [13:00] so there is a newer package [13:00] do you have the apt install log? [13:01] didrocks: https://code.launchpad.net/~autopilot/+junk/apview [13:01] we should maybe "force" the version for the rest [13:01] didrocks: not really :-/ [13:01] didrocks: let me try to ssh to the machine. maybe its around there [13:01] mmrazik: or abort if we see that it wants to install something more than just those packages [13:02] because it means that the stack can't be released alone [13:02] jibel: FYI ^ [13:02] I guess that's what happened, but a confirmation would be good [13:03] didrocks: you mean to abort the build? [13:03] sil2100: oh nice! :) [13:03] (i.e. jenkins build) [13:03] mmrazik: yeah, or exiting on error [13:03] like if we try to install more than just the list specified [13:04] didrocks: are the install logs somewhere around in the system? [13:04] I think jibel is looking for them [13:05] didrocks: http://pastebin.ubuntu.com/1512782/ [13:05] jibel: ^ [13:05] thats from /var/log/apt/history.log [13:05] if I interpret it correctly it indeed upgraded libunity et al [13:06] sil2100: I tend to use fix committed for bugs that actually have the fixed package on its way to the release in the system [13:06] didrocks: I'm not really an expert on preseed, though (where this is happening). I fear that if I remove the "-y" the install will just silently fail but the testing will go on [13:06] sil2100: and in progress until that [13:06] ie. unity-2d still needs the push to the queue, I think? [13:07] mmrazik: yeah, so it's the cause [13:07] mmrazik: I think -y shouldn't be needed, indeed, as we specify all binaries, jibel am I right? [13:08] not sure if a command on preseeding failed if it will failed though [13:08] didrocks, I don't think -y is the problem here, it just answer yes to all prompts but apt will abort if there is an undesirable situation [13:09] jibel: well, the issue is that the ppa is there for it [13:09] jibel: so it's not undesirable [13:09] it will just pull more from the ppa [13:09] which is what we don't want [13:09] (when specifying what we want to install) === Guest39143 is now known as amithkk [13:11] libbamf3-0 became libbamf3-1 [13:11] didrocks, could unity be pulled by dependency ? [13:11] so running the check with only and only the indicator stack should failed [13:11] jibel: right [13:11] as we have a version in the ppa build for unity against libbamf3-1 [13:11] I mean versionned dependency [13:12] well, not versionned, it's a binary package name change due to soname change [13:12] but the result is the same [13:12] so apt is telling "I can't install libbamf3-1 alone" [13:12] "oh, there is a unity in the ppa that can match the dep, let's install it" [13:13] which is what we don't want when installing in the ppa (and don't use "check with whole ppa") [13:13] a solution could be to pin the ppa with high score to not auto-install packages [13:13] the ideal plan is that the install should just fail and that's it. [13:13] jibel: you meant, low score? [13:14] or low I never remember which direction priority goes :) [13:17] didrocks, or if it doesn't work, hold all the packages in the ppa excepted those we want to install/upgrade [13:18] jibel: I wonder if it will work apart from holding, yeah [13:19] and you do think that utah will see the preseeding failing and we'll get the apropriate rejection? [13:19] didrocks, heh, that's another story [13:21] mmrazik: can you try to add to the preseed where we explicit set the packages to install: [13:22] /etc/apt/preferences.d/pinning-ppa with: http://paste.ubuntu.com/1512873/ [13:22] mmrazik: this before the apt-get update [13:22] didrocks: but having that for the unity stack update is no good, right? [13:23] mmrazik: no, only when we provide a package list [13:23] ok [13:23] so that it doesn't impact "build with whole ppa" as well [13:24] sil2100, didrocks: If you have a minute: https://code.launchpad.net/~mc-return/unity/unity.merge-fix-redundant-assignment-of-variables-to-themselves/+merge/142512 [13:25] MCR1: approved, thanks :) [13:25] np [13:27] hehe, thanks === mterry_ is now known as mterry [13:31] didrocks: so anyway, at least I know now that the 8 additional failures are real regressions ;) [13:31] mmrazik: feel free to launch the jenkins job for the indicators once you have done the change (it seems ATI has stalled) [13:31] sil2100: yeah, good to have tests, isn't it? :) [13:31] didrocks: ok [13:31] Indeed! ;) [13:32] sil2100: please keep me posted, and let's try to sync with mterry once here [13:32] didrocks, hello! [13:32] didrocks, I'm mostly back to operational [13:32] oh already around? :) [13:32] it's early for you, isn't it? [13:32] didrocks, yeah early start today, since I'm likely going to be slow to ramp up today (still recovering from hard drive break) [13:33] mterry: urgh, hard drive breakage and real world test of your recovering then? :) [13:34] didrocks, eh, I don't need most of the backup contents for work [13:34] didrocks, that was mostly a million bzr branches and pbuilder chroots and such === dandrader is now known as dandrader|afk [13:34] ah ok, not a great loss fortunately :) [13:35] didrocks, let's hope so. I haven't actually tried to restore my backup yet :) [13:35] sil2100: btw, you should introduce mterry to apview for debugging the autopilot failing tests, it looks nice, indeed :) [13:37] didrocks, so do we have the results of an autopilot run after those couple fixes yesterday? === MacSlow|lunch is now known as MacSlow [13:37] mterry: yep, and there is a regression apparently from those fix (or the bug is not hidden anymore): [13:38] mterry: https://jenkins.qa.ubuntu.com/job/ps-unity-autopilot-release-testing/label=autopilot-nvidia/lastCompletedBuild/ [13:38] mterry: look at the "hud" ones [13:39] The fix that Brandon made shouldn't cause that regression, since hm, it somehow doesn't seem related - but maybe it now leads to a stupid race condition [13:39] I think sil2100 has fixed unity.tests.test_hud.HudBehaviorTests.test_closes_then_focuses_window_on_mouse_down [13:39] right? [13:39] it's the one in the pipe for merging? [13:39] didrocks: ...most probably ;p [13:39] Yes ;) [13:40] didrocks: done but I'm really not sure it will help. I fear that the apt-get install will fail but the process/testing will continue with the old packages [13:41] and also look at run 46/ https://jenkins.qa.ubuntu.com/job/ps-indicators-autopilot-release-testing/ [13:41] mmrazik: let's see how it goes with the logs [13:41] so https://jenkins.qa.ubuntu.com/job/ps-indicators-autopilot-release-testing/label=autopilot-intel/lastCompletedBuild/testReport/ [13:42] and https://jenkins.qa.ubuntu.com/job/ps-indicators-autopilot-release-testing/label=autopilot-nvidia/lastCompletedBuild/testReport/ [13:42] there are those 8 news + the one which should be fixed by now + the _prev/_next one [13:42] mterry: we can have the videos of the test execution, sil2100 can maybe help you with that? [13:43] anyway, I'll let you organize as you prefer, I really need to go out for exercising now or I will become crazy :) [13:43] didrocks, #46 is way better than that first link [13:43] mmrazik: I'll look at run #47 [13:44] mterry: this link is only the hud and indicators tests [13:44] mterry: the other link is all the tests :) [13:44] ah yes [13:45] mmrazik: another solution will be to add a test at start which checks the version of things that are not supposed to be upgraded [13:46] and abort if it fails [13:46] not sure if it's possible [13:47] didrocks: Here another minor improvement: https://code.launchpad.net/~mc-return/unity/unity.merge-reduce-scope-of-some-variables/+merge/142516 [13:49] didrocks: yep. would be possible. Just the whole thing starts to be a hackish bunch of scripts :-/ [13:50] mmrazik: yeah :/ === dandrader|afk is now known as dandrader [13:52] sil2100, so of these 11 current failures I'm seeing in #46, it sounds like you fixed one? (focuses_window_on_mouse_down) I guess I'll look at the panel tests [14:05] in lp:unity/panel/PanelIndicatorEntryView line 263 we can find this: [14:05] gint pos = gtk_widget_path_append_type(widget_path, GTK_TYPE_MENU_BAR); [14:05] line 264: pos = gtk_widget_path_append_type(widget_path, GTK_TYPE_MENU_ITEM); [14:06] line 263 is redundant, but is line 264 the correct one ? [14:08] line 332, 333 the same happens... [14:14] sil2100, I think I understand why a couple of the panel tests fail [14:14] sil2100, the first Alt+F10 does not work [14:14] sil2100, but subsequent ones do [14:15] mterry: I can confirm this observation [14:15] I don't know enough about the codebase to offer a fix, but hopefully one of ya'll do [14:18] mterry: thanks for the info, good catch! [14:18] I'll try to fix this in a moment [14:30] didrocks: ignore #47. It had a faulty preseed. [14:30] just started #48 [14:31] Do we have a handle on the hud regression? [14:51] funny, I can't repro that hud problem manually on a fully updated (from the daily PPA) raring system no matter how hard I try === mmrazik is now known as mmrazik|otp [14:55] bregma, I can [14:55] bregma, I can't, however, repro the hovering indicators panel test [14:56] bregma, oh wait, you mean manually? I was running the autopilot test locally and it failed [14:56] manually, yes [14:56] bregma, so I open an app, open the dash, then press alt? [14:56] would that means the problem is the test and not the target software? [14:57] bregma, I get the bfb icon even doing it manually [14:57] oh, so you expect the dash icon to not show up in the HUD even through the dash was open when you invoked the HUD? [14:58] bregma, that seems to be what the test is testing [14:58] bregma, the test wants the calculator icon to appear in the HUD [14:59] OK, understood now [14:59] I thought that was what https://code.launchpad.net/~sil2100/unity/hud_icon_bfb_fix/+merge/141977 was supposed to fix [15:00] looks like it didn't [15:00] Yes, it was fixing it before actually [15:00] Now it's broken again [15:00] I'll check in a moment what's up [15:02] btw, does anyone have any idea why the global menus have stopped working in raring? They come back if you manually install indicator-appmenu but that smacks of some broken packaging somewhere to me [15:02] didrocks, sil2100: Another one (minor performance optimization): https://code.launchpad.net/~mc-return/unity/unity.merge-remove-assignment-of-values-never-used/+merge/142527 [15:03] bregma, that sounds like I would expect. indicator-appmenu is necessary to show the menus [15:03] bregma, you mean, something uninstalled indicator-appmenu for you? [15:04] it was not installed, and I didn;t notice any packages being uninstalled in my last upgrade [15:04] even if something uninstalled it and I didn't notice (quite possible), it still sounds like broken packaging [15:05] bregma, it could happen if you dist-upgraded before libraries were fully transitioned... [15:05] sure, me and everyone else who is using raring, sounds fishy [15:05] bregma, the package is on the CD [15:06] bregma, they are working for me.. [15:06] did you do a fresh install or an upgrade? [15:06] bregma, upgrade [15:07] bregma, this was yesterday though. Maybe something was temporarily broken in the past [15:07] bregma: the reason for that might be libbamf [15:08] bregma: since we switched recently from libbamf3-0 to libbamf3-1 in packaging [15:08] maybe, and all the people who are complaining about no global menus got caught by it [15:09] my concern is all the people who have been tracking raring: if at least three of us have had this happen then how many non-unity-developers have had it happen? [15:14] bregma: do you have any kind of ppa? many are tracking staging [15:14] bregma: and staging don't have the rebuild of indicator-appmenu against the new bamf [15:14] bregma, i dunno, library transitions happen all the time. apt-get and update-manager both warn you about removing packags [15:14] because of the soname breakage [15:15] didrocks, welcome back! [15:15] mterry: thanks! it's freezing outside :) [15:16] I backlogged, mterry, do you have some tests that you can work on fixing or is sil2100 over them? (at least, nice catch! ;)) [15:16] didrocks, the hovering indicators test I was trying to figure out still [15:16] didrocks, that's the last unknown from the set of 11 === mmrazik|otp is now known as mmrazik [15:17] yes, apparently I have staging in my sources: if that's the cause of the problem I'm not worried [15:17] that would be awesome :) [15:18] bregma: I'm 99.42% sure it's the cause ;) [15:22] didrocks: AFAIC build #48 just didn't install anything and executed the tests :-/ [15:22] didrocks: Could you please take a look @ https://code.launchpad.net/~mc-return/unity/unity.merge-reduce-scope-of-some-variables/+merge/142516 and https://code.launchpad.net/~mc-return/unity/unity.merge-remove-assignment-of-values-never-used/+merge/142527 - I am 99.42% sure they are correct :) [15:23] mmrazik: yeah, the pinning is not good [15:23] MCR1: sorry, if I didn't answer it's because I don't have the time for it right now ;) [15:23] mmrazik: I think the only way right now will be to install [15:24] mmrazik: and having a script parsing the log of this apt-get install [15:24] thaught you might have missed it, sorry 4 stressing ;) [15:24] MCR1: no worry ;) [15:24] mmrazik: and see if there is anything more than the list we gave, wdyt? [15:24] didrocks: yeah... I don't see to many other options either [15:25] mmrazik: you do have the log right, you can abort right away, just having one test and exiting in error? [15:25] I don't know this UTAH thing enough [15:25] well UTAH/linked to jenkins [15:25] me neither. It would be best to fail the installation [15:25] directly in preseed [15:26] I think it's possible to do that in preseed [15:26] like redirect the apt-get install to a file [15:26] and then a stupid script parsing that [15:26] ? [15:28] mterry: wait, hovering indicators? [15:28] It's failing again? [15:28] sil2100, did that get fixed? I'm working off #48 [15:28] mterry: we concluded that it was caused by the switcher fix Brandon did... [15:29] mterry: is the build 48 using the latest unity packages? [15:29] mmrazik: ^ ? [15:30] sil2100, should be. It looks like the latest build [15:30] mterry: since didrocks executed tests using the latest unity in a different jenkins job and the failure wasn't there anymore [15:30] https://jenkins.qa.ubuntu.com/job/ps-unity-autopilot-release-testing/label=autopilot-intel/lastCompletedBuild/testReport/ [15:30] sil2100: no [15:30] Here it was not reproducable anymore [15:30] mterry: oh yeah, don't look at #48 [15:30] I think 48 is broken [15:30] it's our test to install only what we want :) [15:31]