=== _thumper_ is now known as thumper === jono is now known as Guest76484 [07:31] didrocks, hi, i hope you can take a look at this https://code.launchpad.net/~ricotz/gnome-control-center-signon/fix-packaging/+merge/150422 [07:32] ricotz: approved! Thanks :) [07:32] thanks [07:58] Is Jenkins ill ? I am sure this works: https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix808909-addhelper-autostart-fails/+merge/150474 [08:01] mmrazik: Hi :) Can you answer this ? ^^ === davidcalle_ is now known as davidcalle [09:54] Only 3 failures for ibus \o/ [10:02] nice sil2100 :) === mmrazik is now known as mmrazik|lunch === mmrazik|lunch is now known as mmrazik [12:07] didrocks: just looking on the dir structure in cupstream2distro-config and I think we will need sth like stacks/head/jenkins-templates dir [12:08] in the past we have been changing the templates and it would be good to keep the old version for old stacks [12:08] mmrazik: didn't we say that the templates are per "job type" rather? [12:08] like daily-release and so on? [12:09] didrocks: I fear it will be per job type and per release [12:09] but the truth is we can split it once we have an immediate need [12:09] which we don't have ATM [12:10] mmrazik: or the deploy tool can be per release [12:10] mmrazik: like giving a template directory [12:10] didrocks: ack [12:10] mmrazik: btw, rev9 is the last one for now, I'm changing my tools to support this [12:11] (out of tree config stacks) [12:11] the deploy tool is already functional [12:12] ok === _salem is now known as salem_ [13:03] mmrazik: ok, I think I've updated all the tools and write tests for the automated part to the new config and template locations in a flexible manner [13:04] didrocks: ack. I'm a bit stuck trying to generate the yaml from our current configs (its progressing just a bit slower than I thought) [13:05] ack, good luck! :) [13:54] mterry, ping [13:54] Mirv, can you explain your request for compiz 0.9.7.12 again? I don't think I have that code anymore on my hard drive. But I didn't upload that, just provide a patch for it [13:54] mhr3, hi [13:54] mterry, morning, i'd like to ask about the unity stack [13:55] mterry, we'd like updated dee in raring so ppas building related stuff continue working [13:55] which they don't atm [13:56] mhr3, sure [13:56] mhr3, the stack failed to build last night, let me see [13:56] mterry: I mean that the packaging branch is out of date, doesn't have the exact version that is in archives. if it's not found, I need to manually mimick the archive version in my branch before making additional changes [13:57] mterry: who uploaded it eventually? [13:57] Mirv, I think you'll have to do that. You did, it looks like [13:57] mterry, yea, i was talking to didier yesterday he said it's not there cause something down the line failed [13:57] mterry: I don't have upload rights :P [13:57] Mirv, maybe I sponsored your patch then [13:58] mterry: anyhow, if you don't have it, then I'll just grab the archive version and put it on top of my bzr branch [13:58] Mirv, yup, I did [13:58] Mirv, OK, thanks. Sorry for the trouble [13:58] mterry: no problem, the hunt for the distro branches is commonplace.. (a rock solid process/system for that would be welcome) [13:59] Mirv, though really, lp:ubuntu/precise/compiz *should* be up to date. I see that it isn't, but that's the fault of a script [13:59] Mirv, in future, hopefully it's just trunk ;) [13:59] In this post-inline world [14:01] mhr3, OK, I've restarted the stack. Hopefully it will publish this time [14:01] mterry, and if it fails again? [14:02] cyphermox, what's the story with the indicator stack [14:02] ? [14:02] do you an override "but publish this part anyway"? [14:02] *do you have an [14:02] mhr3, it shouldn't. The build failures were transient. Another failure is likely to be transient as well. I can publish manually if I can't get things working as they are [14:03] mterry, ok, let's see what happens then :) [14:05] mterry: yes, the post-inline world is much more sane [14:29] mterry: do you mean the ido build failure? [14:30] cyphermox, the whole thing is yellow/red. I just didn't know if it was serious (i.e. if my unity stack looks OK, is the indicator stack a reason for me not to release) [14:30] heh [14:30] is there anything in unity that depends on new indicators, aside maybe for hud stuff? [14:36] cyphermox, I don't think so... mhr3: do you know of anything in recent unity commits that needs anything special from the indicator stack? [14:36] just finishing up checking but it doesn't look like there is anything [14:37] cyphermox, looks like indicator stack is yellow at least in part because hud has a distro release that needs to land back in trunk [14:38] yeah, I just need to approve your hud merge, and fix up ido by fixing xorg-gtest's mess [14:38] yeah [14:39] mterry: hud done -- [14:40] xorg-gtest was in progress because I still need to finish up some changes in the m4 and then talking to upstream about it, but I should be able to complete that today [14:41] or if not, at least you know, fix ido temporarily enough that it will be happy to build [14:44] mterry, nope, larsu might know about indicators [14:46] cyphermox, ah, thanks for approving the bustle one too [14:48] cyphermox: mterry: kenvandine: robru: FYI, I've changed cupstream2distro to support out of tree config [14:48] didrocks, cool [14:48] meaning now that the deployement tools are in lp:cupstream2distro-config [14:49] robru: already awaken? jetlag? :/ [14:49] didrocks, yeah, jetlag really bad. ;-) [14:49] robru: waow, I hope you won't need yet-another-week of adjustement :) [14:49] didrocks, awesome [14:49] so the stacks are in the stacks directory of lp:cupstream2distro-config [14:50] and cu2d-update-stack in the daily-release directory [14:50] didrocks, is that dee fix still blocked by the unity stack? [14:50] kenvandine: yeah, see the discussion above between mhr3 and mterry ^ [14:50] kenvandine: but hopefully, the new run will all go smoothly :) [14:50] great [14:51] so all, FYI, I changed some parts of the scripts (with tests) to support this new layout [14:52] it can impact the publishing and copy2distro part [14:52] those are under tests, so it should work [14:52] but if you see anything weird, ping/harass me :) [14:52] (I redployed earlier today the new version on prod machines) [14:52] didrocks, OK. This is general cleanup, or do we get new features with this? [14:53] mterry: out of tree with support of subdirectories :-) [14:53] + the 2 fixes from yesterday: [14:53] - support the UNRELEASED case for a one commit only with a changelog content [14:54] - don't use pull-lp-source but use our own process and launchpad credentials supporting multiple LP connection at a time [14:54] cool [14:56] also I moved some of jibel's tool in trunk and remove some hardcoded bits in the template in a default configuration [14:56] like system path and so on [15:03] mterry: your bustle branch was including all the changes currently in distro, right? [15:04] cyphermox, yeah [15:05] oops [15:05] it was in fact missing your change for debian/hud-tools.install [15:07] grr there are lots of differences between the two diffs [15:11] cyphermox, it was? I thought I fixed that [15:12] mterry: yeah, the file wasn't included in that merge [15:12] cyphermox, that's intentional [15:12] oh ok [15:12] there are also some differences in the build-depends, I guess that's another different merge? [15:12] cyphermox, so distro commented out that line in the .install. But my branch fixed the need for the commenting, so I didn't include that change [15:13] ah [15:13] cyphermox, yeah, the build-depends were dropped in distro to prevent it running the tests [15:13] alright [15:13] cyphermox, but the fix allows the tests, so... [15:13] sure [15:13] mterry: makes total sense, I'll just get back to my other stuff [15:13] Hopefully the only change that's worth taking was the changelog [15:13] yep [15:26] didrocks, sil2100: looks like this latest unity run is passing checks fine. ~20 test failures per config. I'm inclined to ratchet down the allowed tests these days, now that ibus and some other great test fixes have landed (thanks sil2100!!). We currently allow 33 failures, 14 regressions. How about we ratchet down to 25 failures, 10 regressions? [15:26] mterry: hi! Let me share a doc with you [15:27] mterry: I like this spirit! :-) [15:27] mterry: np. for the fix - still need to polish the rough edges, since I still see 3 ibus failures [15:27] mterry: you running the current compiz? [15:27] sil2100, yeah, I saw you had a follow-on fix. But it's good progress :) [15:27] cyphermox, yeah [15:27] mterry: I made a document that lists the failures and tries to guess if they're regressions or not [15:27] sil2100, oh! You're the best [15:27] mterry: ok ;) last week we had surprises [15:27] cyphermox: I think you can relaunch indicators :) [15:28] didrocks: beh [15:28] indicators is actually having ido fail to build... [15:28] cyphermox: is it a real one? not transien/timeout? [15:28] mterry: it's based on build 96, so I have to re-do it for the newest one though ;) [15:28] oh, definitely a real ftbfs [15:28] mterry: but some more fixes are landing! Mine just got approved, andyrock prepared another one which I'm reviewing now [15:28] I'll file a merge now to fix this, but it's going to be a temporary fix until I can finish up with xorg-gtest [15:29] sil2100, so counting worse case (the maybes in both categories), we have 13 regressions, 19 failures in that doc [15:30] well, 13 regressions, 26 failures I guess [15:30] I assume those will go down if the doc is updated though [15:31] sil2100, do you think 25 failures, 10 regressions is a reasonable new threshold for failure? Or do you want less/more wiggle room? [15:31] Actually, a lot of these entries are marked FIXED [15:35] mterry, sil2100 unity.tests.launcher.test_icon_behavior.LauncherIconsTests.test_unminimize_minimized_immediately_after_show_windows (Single Monitor) should be fixed in trunk [15:35] unity.tests.launcher.test_keynav.LauncherKeyNavTests.test_launcher_keynav_cancel_on_click_icon(Single Monitor) too [15:38] mterry: hm, let's maybe wait for tomorrow, and if it's still so low, then let's lower the treshold [15:40] fginther, a check job just failed with: [15:40] [workspace] $ /bin/bash -u /tmp/hudson1642251030477968427.sh [15:40] Calculating results for card ati [15:40] /tmp/hudson1642251030477968427.sh: line 22: BASEDIR: unbound variable [15:41] mterry, looking [15:41] didrocks, is there a way to ask the publishing job to run again, but not in a manual-publish way? [15:42] ah... looks like I can in the web interface [15:42] mterry: hum, what's the use case? [15:42] yeah, the web interface should give you that :) [15:42] didrocks, here, we passed all the tests in the check job. But looks like a script malfunction marked the job as a failure. I'd still like the publish job to run to show me all the packaging diffs and such [15:43] And then I'd manually publish if I liked the changes [15:43] mterry: hum, I don't see the failure in the publishing job. That can be due to my changes today [15:43] which run? [15:43] didrocks, no, the publishing job never bothered, since the check failed [15:43] check job 91 [15:44] http://10.97.0.1:8080/job/cu2d-unity-head-2.2check/91/console [15:44] didrocks, ^ [15:44] ahah, so it's my fault :) [15:44] fginther, ^ didrocks says he did it [15:44] mterry: yeah, that was hence the "warning, I changed a lot of things and deployed" [15:44] didrocks, :) [15:44] now, you see it for real :) [15:44] mterry, ack [15:45] * didrocks grr on the templates not being able to test easily [15:46] mterry: found the typo [15:47] ok, further grep sounds like everything should be in shape, let me redeploy with the right template [15:47] mterry: don't run the publisher again now [15:49] mterry: deployed, you can go back to a normal life :) [15:49] cyphermox: your turn, doing the same for the indicator stack [15:52] didrocks, cyphermox : I'm inclined to manually publish the unity stack. Any objections? [15:53] mterry: if the packaging changes looks cool, yeah, the only error was on my side, everything pass :) [15:53] cyphermox: indicators ready [15:53] didrocks, are you using the desktop-team screen? [15:54] mterry: I don't [15:54] I'm not even ;) [15:54] webapps/webcreds done [15:57] hrm... someone was in python/bzr. They seem done [16:01] didrocks, I updated the unity stack to not include unity-scope-video-remote anymore. For that change to go live, I'd have to re-deploy right? [16:03] kenvandine, mhr3: dee published [16:03] mterry, yey! :) [16:15] didrocks, how long does it take for the published packages to appear as pushes to the archive? [16:16] mterry, thanks! [16:19] ah, there it goes [16:28] mterry: publish is a few minutes, then the daemon, is running every 15 minutes on the archive admin box [16:28] didrocks, k. I was just impatient :) [16:28] Could someone please re-approve https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix808909-addhelper-autostart-fails/+merge/150474 [16:28] ? [16:29] It seems panda-pbuilder was somehow failing to build... [16:33] MCR1: indeed, I see the failure is somewhere else - let me reapprove [16:33] sil2100: thx :) === mdeslaur is now known as random_nickname === random_nickname is now known as mdeslaur [16:54] mterry, how much published is dee? :) [16:54] mterry, http://s-jenkins:8080/job/libunity-ferrets-mbs-autolanding/build=pbuilder,distribution=raring,flavor=amd64/11/console [16:56] mhr3, https://launchpad.net/ubuntu/+source/dee shows it uploaded, but not in raring proper yet [16:56] mhr3, so not published from a distro sense. But published from a jenkins sense [16:58] i knew there'd be a gotcha [17:00] mterry, so when can i actually re-approve that branch and expect it to land? [17:01] mhr3, when the +source/dee page shows the version in raring (not just -proposed) [17:02] mterry, can i get an approximate delta in some SU units? ;) [17:03] mhr3, less than 30 min, but likely less than 15min? [17:05] ah, cool [20:10] mhr3, btw, dee landed in raring a few hours ago [21:45] smspillaz: First performance optimizations are already awesome, even on ATI :) Top job !!! === salem_ is now known as _salem