[03:47] <smspillaz> popey: hmm, how did you even get quantal running in virtualbox anyways? Just says here that the Xorg driver isn't current with the xserver shipped in quantal
[03:47] <smspillaz> (I'm trying to have a better look into this driver hang which doesn't involve looking at the source code and guessing
[04:29] <thumper> hi smspillaz
[04:35] <smspillaz> thumper: hey
[04:35] <thumper> smspillaz: how are you doing? study going well?
[04:38] <smspillaz> thumper: yeah good
[06:36] <tjaalton> trying to build unity on a ppa (ripping off barrier code, so I can test it with xserver 1.14), but it fails trying to find Nux/Nux.h? builds fine on my local sbuild
[06:36] <tjaalton> https://launchpadlibrarian.net/131298702/buildlog_ubuntu-raring-amd64.unity_6.12.0daily13.02.08-0ubuntu1.1_FAILEDTOBUILD.txt.gz
[07:12] <tjaalton> bah, I'll just build it on nexus7..
[07:58] <mmrazik> didrocks: can you please paste your message again? I've seen the notification but I can't find the channel where it is
[07:58] <mmrazik> really weird
[07:58] <didrocks> mmrazik: oh, interesting :
[07:58] <didrocks> :)
[07:58] <mmrazik> didrocks: but I wasn't changing the cat. I only checked the indicators
[07:59] <mmrazik> I _think_ I checked the other jobs but maybe not
[07:59] <didrocks> mmrazik: seems oif is failing too
[08:00] <mmrazik> didrocks: should be fixed now
[08:00] <mmrazik> btw. the logging is also not there yet. For some reasons the logs are empty
[08:00] <didrocks> mmrazik: relaunching
[08:00] <mmrazik> need to poke jcollado
[08:00] <mmrazik> today
[08:00] <didrocks> mmrazik: indeed
[08:00] <didrocks> thanks!
[08:03] <didrocks> mmrazik: seems to pass now, thanks :)
[08:31] <sil2100> thomi: ping
[08:49] <popey> smspillaz: using 4.2.6 virtualbox driver
[11:29] <smspillaz> okay
[11:29] <smspillaz> OKAY
[11:29] <smspillaz> I think I've fixed the failing xorg-gtests in CI
[11:31] <smspillaz> https://code.launchpad.net/~compiz-team/compiz/compiz.fix_1120009.3/+merge/148675
[11:31] <smspillaz> sil2100: andyrock: Trevinho: ^ hopefully that should go green soonish
[12:51] <didrocks> hey sil2100
[12:52] <didrocks> sil2100: ok, we finally had one unity building and tests running
[12:52] <didrocks> sil2100: unfortunately, if you look at the run, there are really really a lot of failures :/
[12:52] <didrocks> on every config this time
[12:52] <didrocks> (panel tests it seems and still some switcher ones)
[12:54] <sil2100> hm
[12:55] <sil2100> Ok, preview tests are fixed, but where did all those failures come from?
[12:57] <jibel> didrocks, mmrazik could you review http://paste.ubuntu.com/1657299/ and apply this diff to resources/preseed.cfg in utah-jenkins
[12:57] <mmrazik> jibel: checking
[12:58] <jibel> it's to run the whole command in the chroot and run bzr as user jenkins instead of ubuntu
[12:58] <didrocks> sil2100: well, I don't really know… this can't be a side effect?
[12:58] <didrocks> sil2100: look at what changed since yesterday, only compiz and unity and not a lot of commits
[13:05] <mmrazik> jibel: fixed
[13:05] <jibel> mmrazik, thanks
[13:13] <didrocks> sil2100: ok, need to go running outside, please keep me posted if you spot anything. I didn't see any weird commit
[13:43] <sil2100> smspillaz: btw. https://code.launchpad.net/~compiz-team/compiz/compiz.fix_1120009.3/+merge/148675 again red...
[13:45] <sil2100> didrocks: so, regarding the failing tests - it seems the unity-panel-service is not running
[13:45] <sil2100> Or not running correctly!
[13:45] <sil2100> didrocks: were there some serious changes to the indicators and appmenu?
[13:46] <didrocks> sil2100: we had a new libindicator, but tests were mostly passing
[13:46] <sil2100> I wonder what happened, since the videos clearly show that there is no panel, no indicators
[13:47] <didrocks> sil2100: nothing in /var/crash
[13:47] <didrocks> sil2100: and it's running from the ssh connexion
[13:48] <sil2100> didrocks: and all the menus are visible on the windows too! hmm, I wonder why unity-panel-service is not running
[13:48] <sil2100> didrocks: I remember having a problem like this, but that was when unity-panel-service simply got uninstalled by accident
[13:48] <sil2100> I mean, libindicator-appmenu
[13:51] <didrocks> sil2100: it's installed here
[13:51] <didrocks> and the system is fully installed
[13:54] <sil2100> Indeed, the strange thing is that all machines suffer from the problem
[13:56] <didrocks> sil2100: indeed, you mean, from the video, there is no panel, nothing?
[13:56] <sil2100> didrocks: and also, the panel seems to be empty from the very beginning, so even the first failing test doesn't have anything on it - so it's unlikely that a test broke it
[13:56] <sil2100> didrocks: there is a panel, but it doesn't have the indicators and the menu entries
[13:56] <sil2100> didrocks: the menu entries are on their respective windows
[13:57] <didrocks> sil2100: hum, ok, we need what went wrong, do you have the ppa installed and the same behavior?
[13:57] <didrocks> (starting to upgrading)
[14:01] <didrocks> sil2100: ok, I'm confirming
[14:01] <didrocks> sil2100: starting to purge the ppa
[14:04] <didrocks> sil2100: ok, so the daily-build ppa is indeed broken, raring is fine
[14:04] <didrocks> sil2100: now, the game is going to update package per package to see what regressed
[14:10] <mterry> didrocks, are we talking about the bump in unity test failures or something else?
[14:10] <didrocks> mterry: right
[14:10] <didrocks> mterry: the failures are real
[14:11] <didrocks> mterry: if you install the ppa, you will see no panel
[14:11] <mterry> didrocks, :(
[14:11] <mterry> yay for test suites!
[14:11] <didrocks> right ;) but I told an hour ago I would go outside for running :p
[14:12] <mterry> didrocks, just bring your cell phone and an irc app  :)
[14:12] <didrocks> ahah :)
[14:12] <didrocks> at least, we know the regression is between the latest time we could have a test on at least one arch
[14:12] <didrocks> and this morning
[14:13] <didrocks> meaning between yesterday and now
[14:13] <mterry> didrocks, OK.  Can I help tie down the regression?  We're talking about iterating packages?  isht.  :-/
[14:18] <mterry> sil2100, morning btw!
[14:18] <mterry> (for me I guess)
[14:18] <didrocks> mterry: yeah, it's unity! :)
[14:19] <didrocks> mterry: sorry, my session went crazy after the upgrade
[14:19] <didrocks> so
[14:19] <mterry> didrocks, oh nice.  So it's the unity package?
[14:19] <didrocks> raring -> working
[14:19] <didrocks> unity daily-build ppa -> no indicator, no appmenu
[14:19] <sil2100> Morning!
[14:19]  * sil2100 is on a hangout right now
[14:19] <didrocks> mterry: yeah, and this is between yesterday and today
[14:19] <didrocks> mterry: do you mind having a look? I don't mind doing some exercice now :)
[14:20] <mterry> didrocks, no problems.  So when you said it's unity, you didn't mean you'd narrowed it to the unity package, you were just saying the PPA as a whole?
[14:20]  * mterry will try to narrow it
[14:20] <didrocks> mterry: no, unity as the source package :)
[14:20] <didrocks> so lp:unity is the only guilty!
[14:20] <didrocks> (we don't have ABI break, so I kept raring nux and compiz)
[14:21] <mterry> didrocks, oh good
[14:23] <didrocks> ok, I'm quickly escaping, will be back in ~1h
[14:23] <didrocks> mterry: thanks ;)
[14:23] <sil2100> didrocks: go exercise!
[14:23] <sil2100> I actually thought you're already back!
[14:23] <didrocks> sil2100: will be needed! :)
[14:23] <didrocks> sil2100: no, I couldn't with this issue, started to think it was in the distro with libindicator before
[14:24] <didrocks> but hopefully, not, we didn't break anyone ;)
[14:24]  * didrocks really goes
[14:24] <mterry> So revisions 3153 or up
[14:24] <mterry> of unity trunk.  one of those seems like the culprit
[14:25] <didrocks> mterry: 3151 actually
[14:25] <didrocks> mterry: looking at the changelog in the ppa for unity - 6.12.0daily13.02.14-0ubuntu1
[14:26] <didrocks>   * Automatic snapshot from revision 3150
[14:26] <mterry> didrocks, (A) you're running and (B) those were just test changes, which shouldn't affect your normal runnng
[14:26] <didrocks> ok, you were one step ahead!
[14:26] <didrocks> I'll just go for (A) then :)
[14:26] <mterry> :)
[14:26] <didrocks> thanks again mterry ;)
[14:26] <mterry> andyrock, sil2100, and dednick: are the commits that you made yesterday likely risky?
[14:28] <mmrazik> didrocks, mterry: btw. do you guys know what is the state of libxpathselect  release?
[14:28] <mmrazik> there is some pending autopilot work we would like to do but need libxpathselect in distro first
[14:29] <mterry> mmrazik, let me see
[14:29] <dednick> mterry: not that i can think of
[14:32] <mterry> fginther, why isn't xpathselect's trunk being built as a daily-build package?  It has a pending change
[14:34] <andyrock> mterry, maybe dednick's branch... why?
[14:35] <mterry> andyrock, trunk is in a bad state.  Indicators don't show anymore
[14:35] <mterry> andyrock, and it happened sometime between yesterday and today in the unity source
[14:37] <mterry> Of the four commit suspects, 3154 and 3155 seem innocent enough
[14:39] <smspillaz> sil2100: *cries*
[14:39] <smspillaz> sil2100: lol, 1% pass rate, all of the xorg-gtest tests are passing though \o/
[14:39] <smspillaz> I know why the other ones aren't though
[14:39] <mterry> mmrazik, fyi, seems like xpathselect isn't being built as a package by our autolanding system for some reason.  I asked fginther why.  We'll see
[14:40] <mmrazik> mhm..
[14:40] <mmrazik> let me see
[14:40] <mterry> mmrazik, the past few changes were bundled into a release, but not the last commit for some reason
[14:41] <mmrazik> mterry:  I don't see any merge proposal waiting for merging and the autolanding job seems to have successful history of merges
[14:41] <mmrazik> mterry: the last merge is from Feb 12
[14:41] <mterry> mmrazik, sorry, the autolanding itself is fine.  But the bit that takes trunk and packages it into the daily-build PPA isn't firing
[14:41] <mterry> mmrazik, that last merge should be packaged
[14:42] <mmrazik> mterry: oh... but I don't thin fginther knows something about it
[14:42] <mterry> mmrazik, oh sorry
[14:42] <mmrazik> mterry: I thought its didrocks and jibel who are taking care of that
[14:42] <mterry> mmrazik, OK.  I'm still a little unclear on exactly who manages which chunks.  I usually just whine to fginther for everything.  He's very patient.  :)
[14:42] <mmrazik> :)
[14:43] <mterry> jibel, do you know anything about xselectpath not being packaged in daily-build?
[14:43] <fginther> mterry, morning
[14:43] <mterry> (er, the most recent commit not being packaged anyway)
[14:43] <mterry> fginther, hi!
[14:43] <mterry> fginther, apparently you weren't the person to ask about my problem above, so no worries  :)
[14:44] <fginther> mterry, ah good. I actually had the same question
[14:49] <jibel> jibel, I know nothing about xselectpath, sorry
[14:49] <jibel> mterry, ^
[14:50] <mterry> jibel, hmm.  Is didrocks the guy to ask about the packaging bits then?
[14:51] <mmrazik> mterry: so what actually needs to be done?
[14:51] <mmrazik> I start to be confused
[14:51] <mmrazik> I thought packaging is OK
[14:52] <mmrazik> given there is already stuff like " Releasing 1.1.3daily13.01.23-0ubuntu1 to ubuntu." in the bzr log
[14:52] <mterry> mmrazik, from a trunk perspective, I think it is.  But there is a bit of code that takes trunk, packages it up, and puts it in the daily-build PPA.   And that's not happening for some reason
[14:52] <mterry> mmrazik, it *has* been working.  But isn't right now
[14:52] <mmrazik> didrocks: any idea? ^
[14:52] <mterry> mmrazik, didrocks is out running right now, he'll be back in a bit
[14:52] <mmrazik> ok
[14:53] <mterry> I'm sure it will become clear once we know where the log output for that bit of code is.
[14:55] <jibel> mterry, yes he is, I'm just the little hand that tries to make the machinery work.
[15:03] <sil2100> smspillaz: ;)
[15:04] <sil2100> mterry: not completely sure what could have caused it, but unity didn't have any risky commits related to indicatorsssss
[15:05] <sil2100> huh, why so many sss
[15:05] <sil2100> -ssss
[15:05] <smspillaz> it looks like a gvariant data type
[15:05] <smspillaz> ssssasssiiiuubbbssssiiibbaassss
[15:06] <sil2100> hehe
[15:07] <andyrock> mterry, what about reverting 3156? does it fix the issue?
[15:08] <mterry> andyrock, I'm working on testing with a reversion.  Just building now
[15:08] <andyrock> but it should not be the problem
[15:08] <smspillaz> popey: do I need to fetch those drivers from somewhere ?
[15:11] <popey> smspillaz: hmm?
[15:12] <popey> smspillaz: oh, virtualbox? I'm using the 4.2.6 from upstream virtualbox.org website and the extensions that came with it
[15:13] <smspillaz> okay, I'll give thta a shot
[15:14] <sil2100> andyrock: it shouldn't be the issue, no panel specific code was changed, right?
[15:14] <sil2100> andyrock: just dash/launcher
[15:15] <andyrock> sil2100, right
[15:15] <andyrock> sil2100, mterry are we sure that the problem is unity?
[15:15] <andyrock> mterry, and what indicators fail to show?
[15:16] <sil2100> andyrock: all indicators fail to show, along with the appmenu
[15:16] <mterry> andyrock, all of them.  didrocks said he confirmed it was in the unity source package.  I'm going to reconfirm once this build is done
[15:18] <sil2100> Maybe its some dependency problem? ABI mismatch? In libindicator-dev ?
[15:19] <sil2100> mterry, andyrock: since look at: http://bazaar.launchpad.net/~indicator-applet-developers/libindicator/trunk.13.04/revision/475
[15:20] <sil2100> Although I don't see any risky changes there
[15:22] <sil2100> Since the libindicator versions used is 12.10.2daily13.02.15-0ubuntu1
[15:29] <andyrock> mterry, sil2100 confirmed the problem should be unity
[15:29] <mterry> me too
[15:29] <mterry> just now  :)  sil2100, stop being faster than me
[15:29] <mterry> am testing the reverted version
[15:30] <mterry> revision 3153 still has the problem
[15:31] <andyrock> mterry, rev 3156 is not the problem btw
[15:33] <mterry> andyrock, yar, now I'm testing against 3152
[15:36] <andyrock> mterry, i get this running unity-panel-service:
[15:37] <andyrock> http://paste.ubuntu.com/1658271/
[15:38] <mterry> andyrock, ah...  the indicators got multiarch'd accidentally
[15:38] <mterry> rather, not the indicators, but the panel service
[15:38] <sil2100> Those changed to multiarch?
[15:38] <sil2100> When did it change?
[15:39] <mterry> sil2100, they didn't, but the panel service is looking for them in a multiarch location
[15:40] <mterry> hence the bug
[15:40] <sil2100> I wonder why then
[15:41] <bregma> dh 9?
[15:43] <didrocks> doh, cycling at this hours to the park isn't friendly, too many cars on Friday evening
[15:44] <sil2100> Cycling?
[15:45] <sil2100> There's snow in Poland, I would freeze my hands off
[15:45] <sil2100> ;)
[15:45] <didrocks> heh, today, the temperature is 4/6°
[15:45] <didrocks> so it's ok :)
[15:45] <mterry> hi didrocks
[15:45] <didrocks> hey mterry
[15:46] <didrocks> backlogging, one sec :)
[15:46] <mterry> hmm, unity is pulling that dir from indicator .pc file
[15:46] <sil2100> So indicators package problem as suspected, hm?
[15:46] <didrocks> oh, interesting
[15:47] <didrocks> so built against latest indicator, the unity panel service is looking on a wrong location
[15:47] <andyrock> mterry, pkg-config indicator3-0.4 --variable indicatordir
[15:47] <andyrock> gives me
[15:47] <andyrock> /usr/lib/x86_64-linux-gnu/indicators3/7/
[15:48] <mterry> andyrock, that's wrong then
[15:48] <mterry> so it seems like libindicator3 after all
[15:48] <andyrock> so the problem was not unity, just unity building using last libindi...
[15:48] <mterry> looks like it
[15:48] <andyrock> *build unity using...
[15:49] <didrocks> mterry: yeah, it's my code doing all the preparation in the ppa
[15:50] <didrocks> mterry: let me look, it's an interesting case, as xselectpath is passing the first step (at least one commit to release), the second one (version >= to distro) but the last one, diff with old package, seems to tell there is nothing to do
[15:51] <didrocks> mterry: see https://jenkins.qa.ubuntu.com/view/cu2d/view/Misc.%20Head/job/cu2d-misc-head-1.1prepare-xpathselect/60/console for logs and details :)
[15:51] <mterry> didrocks, k
[15:52] <mterry> as for the indicators thing, rev 475 of libindicator seems to be the culprit.  it's a big indicator rewrite
[15:52] <didrocks> mterry: yeah, that and moving to dh9
[15:52] <didrocks> but the indicator itself is working
[15:52] <didrocks> it's just the .pc file which seems guilty, right?
[15:53] <bregma> dh9 sets --libdir=multiarchpath, taht's why everything is messed up
[15:53] <mterry> didrocks, yeah.  it uses libdir, but should be hardcoded
[15:53] <didrocks> mterry: mind doing that? or cyphermox, maybe on Monday, we'll have daily finally :p
[15:54] <didrocks> bregma: well, we can still use /usr/lib/x86_64-linux-gnu/libindicator3.so.7.0.0, this one is working :)
[15:54] <mterry> didrocks, I can do
[15:54] <didrocks> thanks!
[15:54] <didrocks> looking at why xpathselect isn't happy
[15:54] <didrocks> first real cupstream2distro bug :) (I don't count the changelog with 2 names a bug :p)
[15:55] <cyphermox> didrocks: doing what?
[15:55] <cyphermox> xpathselect or libdir fixes?
[15:55] <didrocks> cyphermox: read the backlog ;) (but mterry is handling it)
[15:55] <didrocks> no libdir ;)
[15:55] <didrocks> xpathselect, it seems to be in my code
[15:55] <cyphermox> ok
[15:56] <cyphermox> ah, yeah
[15:56] <cyphermox> I was looking at that, but couldn't understand what was up
[15:56] <didrocks> this is weird, because we had that case a lot already
[15:56] <didrocks> my only explanation is that the filterdir is empty
[15:56] <cyphermox> it seems to be finding the right versions numbers too
[15:56] <didrocks> yep
[15:57] <didrocks> it's just when diffing from the distro version
[15:57] <didrocks> (the 3rd state)
[15:57] <didrocks> which is telling "nothing interesting"
[15:57] <cyphermox> didrocks: mind adding the output of the version numbers it finds too?
[15:57] <cyphermox> that might help
[15:58] <didrocks> cyphermox: it's not the issue, it's continuing after the version numbers ;)
[15:58] <cyphermox> oh, I know
[15:58] <didrocks> cyphermox: but yeah, we can archive that
[15:58] <didrocks> one sec, running the diff
[15:58] <cyphermox> but just getting to know that it was going far enough because the versions were fine was a little painful
[15:58] <cyphermox> I had to mess around with the code, because it tries to do funny things with launchpadlib creds
[15:58] <didrocks> cyphermox: hum? the log is clear that it's then downloading from distro and making the diff?
[15:59] <cyphermox> didrocks: I like to start from the beginning to really understand what goes on ;)
[15:59] <didrocks> ok, will add that
[15:59] <cyphermox> ohh wait
[15:59] <cyphermox> I remember something
[16:01] <cyphermox> maybe I'm misremembering, but : if not tip_bzr_rev > last_upstream_rev + num_uploads:
[16:01] <cyphermox> (in is_new_release_needed())
[16:01] <cyphermox> tip_bzr_rev when I looked was 30
[16:01] <cyphermox> last_upstream_rev was 28
[16:01] <cyphermox> and num_uploads was 2 ;)
[16:02] <cyphermox> didrocks: that's in packagemanager.py
[16:02] <didrocks> cyphermox: right
[16:03] <didrocks> oh, I know
[16:03] <didrocks> cyphermox: good catch, it's incremented, but it shouldn't if it's UNRELEASED
[16:03] <cyphermox> ah!
[16:04] <cyphermox> thought it had to do with that UNRELEASED entry, but I was looking at the wrong piece of code
[16:04] <didrocks> the culpurit is:
[16:04] <didrocks>         # end of a changelog stenza (without getting the automated tag) means a manual upload
[16:04] <didrocks>         if new_changelog_regexp.match(line):
[16:04] <didrocks>             num_uploads += 1
[16:05]  * didrocks opens a bug to remember having a test case for that
[16:05] <cyphermox> haha
[16:05] <cyphermox> I was looking at REV_STRING_FORMAT until I figured out what it was ;)
[16:06] <didrocks> cyphermox: yeah, I tried to put all regexp in settings.py
[16:06] <cyphermox> didrocks: so, should be NEW_CHANGELOG_PATTERN = "^{} \((?!UNRELEASED)" ?
[16:06] <didrocks> cyphermox: so that all detections and trickeries are matching the day we change the syntax
[16:07] <didrocks> hum, why "(?"
[16:07] <cyphermox> wait, that's all wrong
[16:07] <cyphermox> didrocks: NEW_CHANGELOG_PATTERN = "^{} \(.*\) (?!UNRELEASED)"
[16:07] <cyphermox> (?! is a negative look-ahead
[16:08] <cyphermox> matches if UNRELEASED doesn't follow
[16:08] <cyphermox> there shouldn't be parens anywhere else so that regex is probably sufficient
[16:08] <mterry> https://code.launchpad.net/~mterry/libindicator/non-multiarch-indicatordir/+merge/148746
[16:09] <mterry> that has the multiarch fix ^
[16:09] <didrocks> cyphermox: I need to check if this has side-effects
[16:09] <didrocks> cyphermox: mind testing mterry's fix? :)
[16:09] <didrocks> cyphermox: ok, let's put that in production next week anyway, I'll get a bunch of tests during the train trip
[16:10] <cyphermox> ^{} \([^)]*\) (?!UNRELEASED)
[16:10] <cyphermox> is safer I think
[16:10] <cyphermox> mterry: checking
[16:10] <sil2100> mterry: looking nice
[16:10] <cyphermox> but why not multiarch?
[16:10]  * cyphermox reads backlog
[16:10] <sil2100> mterry: set the commit message!
[16:10] <mterry> sil2100, shoot, thanks
[16:11] <cyphermox> damn commit message
[16:11] <didrocks> cyphermox: mind commenting on https://bugs.launchpad.net/cupstream2distro/+bug/1126376?
[16:11] <didrocks> with your regexp
[16:11] <mterry> cyphermox, no multiarch for those directories just because of historical reasons
[16:12] <cyphermox> shouldn't we eventually migrate them to multiarch when possible?
[16:13] <mterry> cyphermox, yes, probably with a fallback to the non-multi-arch location
[16:13] <mterry> cyphermox, but that would be a touch of work and coordination
[16:13] <mterry> cyphermox, whereas right now I just want things back to normal to fix the build
[16:13] <cyphermox> yeah
[16:13] <mterry> cyphermox, I think this was an unintentional change
[16:13] <cyphermox> but I thought the indicators were installed to multiarch locations since a long time
[16:14] <mterry> cyphermox, they sort of are.   The services are usually multiarch.  And they are dh9 packages.  But they pull the non-multiarch location from the libindicator pc file
[16:14] <cyphermox> oh, I see
[16:15] <cyphermox> yeah, let's revert that but let's also try to migrate them properly soon
[16:15] <mterry> cyphermox, probably, we should add a non-multiarch variable to the libindicator .pc file for completeness, and have unity look in both that and the normal (now multiarch) location
[16:15] <mterry> as each indicator gets built, it would migrate to the multiarch location, but old ones would still work
[16:16] <didrocks> mterry: if we don't open a bug report for it, please put something in debian/changelog directly :)
[16:16] <mterry> didrocks, I'll open a bug
[16:16] <didrocks> great! :)
[16:16] <mterry> didrocks, I opened a bug for the build problem today.  But I'll also open a bug for the eventual migration
[16:16] <didrocks> perfect :)
[16:17] <didrocks> then we can relaunch indicator
[16:17] <didrocks> and then unity
[16:17] <didrocks> and maybe maybe
[16:17] <didrocks> we'll have finally an unity release :)
[16:17] <cyphermox> yay
[16:17] <didrocks> as it seems sil2100 fixes worked
[16:17] <cyphermox> testing the fix, I'll approve in a few minutes
[16:17] <didrocks> cyphermox: just wait that the merge is linked to a bug before approving
[16:21] <mterry> didrocks, bug 1126385
[16:21] <mterry> cyphermox, ^
[16:21] <cyphermox> cool
[16:23] <didrocks> mterry: thanks! one linked to your branch and tested, cyphermox can approve I guess and let's get things kicked! ;)
[16:24] <mterry> didrocks, we still won't have unity release likely.  I don't think the tests have been fixed yet
[16:25] <mterry> Plus, still super waiting for the ibus test fixes to be reviewd
[16:26] <didrocks> mterry: are you sure? the dash failing are way fewer than before, isn't it?
[16:27] <sil2100> mterry: what tests failing? The dash preview tests that broke the daily build yesterday got fixed hopefully
[16:27] <didrocks> test_dash is -10
[16:27] <didrocks> sil2100: I can still see 5 of them
[16:27] <mterry> sil2100, oh that's right, that commit landed
[16:27] <didrocks> on intel for instance
[16:27] <sil2100> mterry: so we should be a bit better now, at least enough
[16:27] <sil2100> didrocks: yes, there's still the problem with sometimes broken geometry in the dash
[16:27] <mterry> sil2100, let's hope so.  Who's arm do I have to twist to approve your ibus branch?
[16:28] <didrocks> arms? I thought mterry lived in USA and would handle that with guns :)
[16:29] <mterry> didrocks, I live in the wussy liberal part
[16:29] <sil2100> mterry: hehe, well, it seems thomi had some problems running it properly, so I'm investigating this - I think that on Monday it should be landed
[16:29] <didrocks> mterry: I won't say the educated part because tedg is around :)
[16:29] <sil2100> I want thomi to take another look before it lands finally
[16:30] <cyphermox> mterry: we're just waiting for jenkins now!
[16:30] <mterry> sil2100, ah cool
[16:30]  * tedg hides
[16:30] <didrocks> fginther: do you mind helping getting things in quickly? ^
[16:30] <tedg> (easier to get the surprise shot that way)
[16:30] <didrocks> :)
[16:31] <fginther> didrocks, reading the backlog
[16:32] <didrocks> fginther: do you mind helping our dear jenkins friend merging https://code.launchpad.net/~mterry/libindicator/non-multiarch-indicatordir/+merge/148746?
[16:32] <didrocks> (it's just that we have high hope there)
[16:33] <fginther> yep, I'll approve and kick off the job
[16:33] <didrocks> fginther: excellent, thanks!
[16:57] <cyphermox> didrocks: bregma: anyone still actively maintains xorg-gtest?
[16:57] <didrocks> cyphermox: since cnd left, I doubt about it
[16:57] <bregma> upstream, in Debian, or in Ubuntu?
[16:57] <cyphermox> that's what I feared ;)
[16:57] <cyphermox> bregma: any of the above
[16:58] <bregma> upstream is Peter Hutterer at freedesktop.org, I'm trying my best in Ubuntu, and I'm looking for a sponsor in Debian
[16:59] <bregma> the package in Ubuntu is up-to-date with the latest upstream
[17:00] <didrocks> bregma: didn't smspillaz mentionned that a 0.8 exists?
[17:00] <cyphermox> ugh
[17:00] <bregma> he mentioned it, but I think he was confused
[17:00] <didrocks> ok, that's why I tought nobody actively maintained it, because of that :)
[17:01] <didrocks> good to know you are trying to keep it up to date! :)
[17:01] <cyphermox> ok so we're depending on libgtest-dev in libxorg-gtest-dev already
[17:01] <bregma> upstream: http://cgit.freedesktop.org/xorg/test/xorg-gtest/
[17:01] <didrocks> bregma: yeah, seems it's pretty fresh :)
[17:02] <cyphermox> I think I'll fix things up in a few patches and propose them upstream
[17:02] <bregma> no objections from me
[17:02] <seb128> bregma, didrocks: cnd seems still active on it, http://cgit.freedesktop.org/~cndougla/xorg-gtest
[17:03] <bregma> that's almost a year old
[17:03] <didrocks> yeah, that's what I wanted to say :)
[17:04] <seb128> bregma, didrocks: ignore me, I didn't update to 2013 yet it seems :p
[17:04]  * didrocks sudo seb128 update
[17:04] <seb128> didrocks, sudo seb128 ntpdate ouais :p
[17:04] <didrocks> ahah ;)
[17:19] <didrocks> fginther: are you sure you pressed the right button? https://code.launchpad.net/~mterry/libindicator/non-multiarch-indicatordir/+merge/148746 :)
[17:19] <didrocks> seeing the -ci build didn't took a long time
[17:19] <didrocks> but the actual merge seems to
[17:20] <fginther> didrocks, yes i screwed up initially, it's merging as we speak
[17:20] <didrocks> ok, thanks fginther :)
[17:20] <fginther> ah, done!
[17:20] <didrocks> sweet! :)
[17:21] <didrocks> cyphermox: mterry: so not sure if you'll be there if you run the 2 stacks for rebuilding (indicator: complete run as the rest was published, unity: only the unity one for rebuilding). If you think you won't be around once published, it can wait Monday now
[17:22] <mterry> didrocks, I probably won't.  I'm only supposed to be a half day today
[17:22] <mterry> But I can look at it over the weekend
[17:22] <didrocks> yeah, so I would say let's wait on Monday :)
[17:23] <didrocks> mterry: wifi on the plane? ;)
[17:23] <didrocks> mterry: don't worry at this point maybe…
[17:23] <mterry> didrocks, well, tomorrow morning
[17:23] <didrocks> it's the week-end for a reason! :)
[17:36] <cyphermox> didrocks: not to worry, I can do it
[17:37] <didrocks> cyphermox: ok, thanks for monitoring! I'll leave soon :)
[17:37] <cyphermox> so I should run the 2 stacks now?
[17:37] <didrocks> cyphermox: so ./cu2d-run -R indicators
[17:37] <didrocks> then
[17:37] <cyphermox> ok
[17:37] <didrocks> ./cu2d-run -R unity unity
[17:37] <cyphermox> ack
[17:37] <cyphermox> any time?
[17:37] <didrocks> (just wait 5/10 seconds between the 2)
[17:38] <didrocks> the indicators stack needs to cleanswap first to block the unity one
[17:38] <didrocks> you should see the 0waitonestacks job running and blocking the rest :)
[17:39] <cyphermox> didrocks: just a second
[17:39] <cyphermox> where's that job?
[17:39] <didrocks> cyphermox: https://jenkins.qa.ubuntu.com//view/cu2d/view/Unity%20Head/
[17:39] <didrocks> second one
[17:39] <cyphermox> ok got it
[17:39] <didrocks> it only appears when a stack is depending on another one
[17:39] <didrocks> that's why the indicator doesn't have one :)
[17:39] <cyphermox> indicators needs --check-with-whole-ppa btw ;)
[17:39] <didrocks> (of course, this is automagically generated)
[17:39] <didrocks> cyphermox: hum no
[17:40] <didrocks> cyphermox: --check-with-whole-ppa doesn't rebuild anything
[17:40] <cyphermox> humm, yeah, it won't run otherwise
[17:40] <didrocks> but yeah, the tests would fail
[17:40] <didrocks> oh no
[17:40] <didrocks> they won't
[17:40] <didrocks> why?
[17:40] <cyphermox> 2013-02-15 12:38:40,282 ERROR No project or check-with-whole-ppa parameter specified on the command line. This tool is used for those cases. Aborting!
[17:40] <didrocks> argh, yeah, beat by my tool
[17:40] <cyphermox> we'll need to rerun everything
[17:40] <didrocks> I thought this case won't happen TBH
[17:40] <cyphermox> I'll fix it
[17:40] <didrocks> like we want to rerun everything :p
[17:40] <cyphermox> yeah
[17:40] <didrocks> cyphermox: use the web ui
[17:41] <cyphermox> ah
[17:41] <didrocks> go to the head of indicators
[17:41] <didrocks> get logged
[17:41] <cyphermox> we could have made a --all ?
[17:41] <didrocks> then run manually
[17:41] <didrocks> cyphermox: ah, to explicitely force?
[17:41] <cyphermox> yeah
[17:41] <cyphermox> for now I'll use the UI
[17:41] <didrocks> cyphermox: that's a possibility, we won't loose the "ooppsss, didn't specify a project"
[17:41] <cyphermox> right
[17:41] <didrocks> I like it :)
[17:41] <didrocks> but yeah, the UI for indicators first
[17:42] <didrocks> then the tool with only unity for the unity stack
[17:42] <didrocks> cyphermox: so, on run, don't specify anything in projects, nor check "with whole ppa"
[17:42] <cyphermox> yeah I know
[17:42] <didrocks> great :-)
[17:43] <didrocks> ok, started, now you can just build unity in the unity stack
[17:43] <didrocks> and we should see the depwait :p
[17:44] <cyphermox> yeah
[17:45] <cyphermox> awesome, all good
[17:45] <didrocks> \o/
[17:45] <didrocks> cyphermox: thanks for monitoring those :)
[17:48] <cyphermox> in the meantime I'll finish fixing up xorg-gtest
[17:48] <didrocks> good luck :)
[17:48] <didrocks> cyphermox: your tests with dbus-test-runner were successful I guess?
[17:48] <didrocks> as I thought you got it merged
[17:48] <cyphermox> yeah seems good
[17:48] <didrocks> sweet :)
[17:49] <cyphermox> libappindicator was stuck yesterday in uubuntu-unity ppa too
[17:49] <didrocks> ah?
[17:49] <cyphermox> so dbus-test-runner has already landed in distro this morning
[17:49] <didrocks> right
[17:49] <didrocks> let's see how it goes
[17:49] <didrocks> and crossing fingers :)
[17:49] <cyphermox> yup yup
[23:13] <smspillaz> hah, awesome: https://jenkins.qa.ubuntu.com/job/compiz-pbuilder/build=pbuilder,distribution=raring,flavor=amd64/433/console
[23:24] <bschaefer> smspillaz, o my! \o/ 100% tests passed, 0 tests failed out of 1175
[23:24] <bschaefer> smspillaz, that is impressive, sometimes its hard to keep ~200 on unitys unit tests passing
[23:30] <smspillaz> bschaefer: well, it was just getting the xorg-gtest ones working which was a pain
[23:30] <smspillaz> because there's a race in xorg-gtest which can cause some tests to fail randomly
[23:31] <smspillaz> bschaefer: it still seems to be autoloading the ccp plugin during those tests though, which seems to be harmless for now but is definitely the wrong behaviour
[23:32] <bschaefer> yeah i noticed that race with the server not being found
[23:33] <smspillaz> the "workaround" is to just keep calling xorg::testing::Test::SetUp until it doesn't throw an exception -.-
[23:33] <smspillaz> its pretty horrific, but then SetUp doesn't have any side-effects from being called multiple times
[23:33] <bschaefer> smspillaz,  ooo,well it works haha
[23:34] <bschaefer> smspillaz, could you add a timer at the end of each tests?
[23:34] <bschaefer> smspillaz, or is the race condition something that can't be avoided
[23:34] <smspillaz> bschaefer: there already is a timer
[23:34] <smspillaz> kind of
[23:35] <bregma> xorg-gtest fails its own unit test suite randomly in pbuilders, and I can never force it to happen manually
[23:35] <smspillaz> if SetUp throws an exception, I'm just waiting around 50ms and trying again
[23:35] <smspillaz> it sucks, but its better than using timers because this actually gets around the race and doesn't just make it less likely to happen
[23:35] <smspillaz> bregma: running it through valgrind will do it
[23:35] <bschaefer> geez, is there a max number of tries?
[23:35] <smspillaz> bschaefer: yeah, it tries about 10 times before it gives up
[23:36] <bschaefer> smspillaz, cause you don't want an endless loop ;)
[23:36] <smspillaz> gotta run
[23:36] <bschaefer> alright cya
[23:37] <smspillaz> bregma: bschaefer: the problem is afaict that starting a server then calling XOpenDisplay is inherently racey. There's no way to know that the server is fully started other than by trying to connect to it
[23:37] <bregma> feel free to open a bug against xorg-gtest
[23:39] <bregma> there's no upstream bug tracker but you could open bugs against the package in Ubuntu and the guy maintaining the packaging might do something about it :)
[23:39] <bschaefer> that would be nice
[23:40] <smspillaz> bregma: I remember speaking to who-t about this
[23:40] <smspillaz> its not so simple iirc
[23:41] <bregma> no, the race condition can't be fixed because there's no handshake, and even doing an inotify wait on the Unix socket in /tmp is racy
[23:43] <bschaefer> I don't haven a problem withs sams workaround, it works well