[03:47] 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] (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] hi smspillaz [04:35] thumper: hey [04:35] smspillaz: how are you doing? study going well? [04:38] thumper: yeah good [06:36] 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] https://launchpadlibrarian.net/131298702/buildlog_ubuntu-raring-amd64.unity_6.12.0daily13.02.08-0ubuntu1.1_FAILEDTOBUILD.txt.gz [07:12] bah, I'll just build it on nexus7.. [07:58] 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] really weird [07:58] mmrazik: oh, interesting : [07:58] :) [07:58] didrocks: but I wasn't changing the cat. I only checked the indicators [07:59] I _think_ I checked the other jobs but maybe not [07:59] mmrazik: seems oif is failing too [08:00] didrocks: should be fixed now [08:00] btw. the logging is also not there yet. For some reasons the logs are empty [08:00] mmrazik: relaunching [08:00] need to poke jcollado [08:00] today [08:00] mmrazik: indeed [08:00] thanks! [08:03] mmrazik: seems to pass now, thanks :) [08:31] thomi: ping [08:49] smspillaz: using 4.2.6 virtualbox driver === mmrazik is now known as mmrazik|lunch [11:29] okay [11:29] OKAY [11:29] I think I've fixed the failing xorg-gtests in CI [11:31] https://code.launchpad.net/~compiz-team/compiz/compiz.fix_1120009.3/+merge/148675 [11:31] sil2100: andyrock: Trevinho: ^ hopefully that should go green soonish === mmrazik|lunch is now known as mmrazik === _salem is now known as salem_ [12:51] hey sil2100 [12:52] sil2100: ok, we finally had one unity building and tests running [12:52] sil2100: unfortunately, if you look at the run, there are really really a lot of failures :/ [12:52] on every config this time [12:52] (panel tests it seems and still some switcher ones) [12:54] hm [12:55] Ok, preview tests are fixed, but where did all those failures come from? [12:57] didrocks, mmrazik could you review http://paste.ubuntu.com/1657299/ and apply this diff to resources/preseed.cfg in utah-jenkins [12:57] jibel: checking [12:58] it's to run the whole command in the chroot and run bzr as user jenkins instead of ubuntu [12:58] sil2100: well, I don't really know… this can't be a side effect? [12:58] sil2100: look at what changed since yesterday, only compiz and unity and not a lot of commits [13:05] jibel: fixed [13:05] mmrazik, thanks [13:13] sil2100: ok, need to go running outside, please keep me posted if you spot anything. I didn't see any weird commit [13:43] smspillaz: btw. https://code.launchpad.net/~compiz-team/compiz/compiz.fix_1120009.3/+merge/148675 again red... [13:45] didrocks: so, regarding the failing tests - it seems the unity-panel-service is not running [13:45] Or not running correctly! [13:45] didrocks: were there some serious changes to the indicators and appmenu? [13:46] sil2100: we had a new libindicator, but tests were mostly passing [13:46] I wonder what happened, since the videos clearly show that there is no panel, no indicators [13:47] sil2100: nothing in /var/crash [13:47] sil2100: and it's running from the ssh connexion [13:48] didrocks: and all the menus are visible on the windows too! hmm, I wonder why unity-panel-service is not running [13:48] didrocks: I remember having a problem like this, but that was when unity-panel-service simply got uninstalled by accident [13:48] I mean, libindicator-appmenu [13:51] sil2100: it's installed here [13:51] and the system is fully installed [13:54] Indeed, the strange thing is that all machines suffer from the problem [13:56] sil2100: indeed, you mean, from the video, there is no panel, nothing? [13:56] 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] didrocks: there is a panel, but it doesn't have the indicators and the menu entries [13:56] didrocks: the menu entries are on their respective windows [13:57] sil2100: hum, ok, we need what went wrong, do you have the ppa installed and the same behavior? [13:57] (starting to upgrading) [14:01] sil2100: ok, I'm confirming [14:01] sil2100: starting to purge the ppa [14:04] sil2100: ok, so the daily-build ppa is indeed broken, raring is fine [14:04] sil2100: now, the game is going to update package per package to see what regressed [14:10] didrocks, are we talking about the bump in unity test failures or something else? [14:10] mterry: right [14:10] mterry: the failures are real [14:11] mterry: if you install the ppa, you will see no panel [14:11] didrocks, :( [14:11] yay for test suites! [14:11] right ;) but I told an hour ago I would go outside for running :p [14:12] didrocks, just bring your cell phone and an irc app :) [14:12] ahah :) [14:12] at least, we know the regression is between the latest time we could have a test on at least one arch [14:12] and this morning [14:13] meaning between yesterday and now [14:13] didrocks, OK. Can I help tie down the regression? We're talking about iterating packages? isht. :-/ [14:18] sil2100, morning btw! [14:18] (for me I guess) [14:18] mterry: yeah, it's unity! :) [14:19] mterry: sorry, my session went crazy after the upgrade [14:19] so [14:19] didrocks, oh nice. So it's the unity package? [14:19] raring -> working [14:19] unity daily-build ppa -> no indicator, no appmenu [14:19] Morning! [14:19] * sil2100 is on a hangout right now [14:19] mterry: yeah, and this is between yesterday and today [14:19] mterry: do you mind having a look? I don't mind doing some exercice now :) [14:20] 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] mterry: no, unity as the source package :) [14:20] so lp:unity is the only guilty! [14:20] (we don't have ABI break, so I kept raring nux and compiz) [14:21] didrocks, oh good [14:23] ok, I'm quickly escaping, will be back in ~1h [14:23] mterry: thanks ;) [14:23] didrocks: go exercise! [14:23] I actually thought you're already back! [14:23] sil2100: will be needed! :) [14:23] sil2100: no, I couldn't with this issue, started to think it was in the distro with libindicator before [14:24] but hopefully, not, we didn't break anyone ;) [14:24] * didrocks really goes [14:24] So revisions 3153 or up [14:24] of unity trunk. one of those seems like the culprit [14:25] mterry: 3151 actually [14:25] mterry: looking at the changelog in the ppa for unity - 6.12.0daily13.02.14-0ubuntu1 [14:26] * Automatic snapshot from revision 3150 [14:26] didrocks, (A) you're running and (B) those were just test changes, which shouldn't affect your normal runnng [14:26] ok, you were one step ahead! [14:26] I'll just go for (A) then :) [14:26] :) [14:26] thanks again mterry ;) [14:26] andyrock, sil2100, and dednick: are the commits that you made yesterday likely risky? [14:28] didrocks, mterry: btw. do you guys know what is the state of libxpathselect release? [14:28] there is some pending autopilot work we would like to do but need libxpathselect in distro first [14:29] mmrazik, let me see [14:29] mterry: not that i can think of [14:32] fginther, why isn't xpathselect's trunk being built as a daily-build package? It has a pending change [14:34] mterry, maybe dednick's branch... why? [14:35] andyrock, trunk is in a bad state. Indicators don't show anymore [14:35] andyrock, and it happened sometime between yesterday and today in the unity source [14:37] Of the four commit suspects, 3154 and 3155 seem innocent enough [14:39] sil2100: *cries* [14:39] sil2100: lol, 1% pass rate, all of the xorg-gtest tests are passing though \o/ [14:39] I know why the other ones aren't though [14:39] 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] mhm.. [14:40] let me see [14:40] mmrazik, the past few changes were bundled into a release, but not the last commit for some reason [14:41] mterry: I don't see any merge proposal waiting for merging and the autolanding job seems to have successful history of merges [14:41] mterry: the last merge is from Feb 12 [14:41] 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] mmrazik, that last merge should be packaged [14:42] mterry: oh... but I don't thin fginther knows something about it [14:42] mmrazik, oh sorry [14:42] mterry: I thought its didrocks and jibel who are taking care of that [14:42] 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] :) [14:43] jibel, do you know anything about xselectpath not being packaged in daily-build? [14:43] mterry, morning [14:43] (er, the most recent commit not being packaged anyway) [14:43] fginther, hi! [14:43] fginther, apparently you weren't the person to ask about my problem above, so no worries :) [14:44] mterry, ah good. I actually had the same question [14:49] jibel, I know nothing about xselectpath, sorry [14:49] mterry, ^ [14:50] jibel, hmm. Is didrocks the guy to ask about the packaging bits then? [14:51] mterry: so what actually needs to be done? [14:51] I start to be confused [14:51] I thought packaging is OK [14:52] given there is already stuff like " Releasing 1.1.3daily13.01.23-0ubuntu1 to ubuntu." in the bzr log [14:52] 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] mmrazik, it *has* been working. But isn't right now [14:52] didrocks: any idea? ^ [14:52] mmrazik, didrocks is out running right now, he'll be back in a bit [14:52] ok [14:53] I'm sure it will become clear once we know where the log output for that bit of code is. [14:55] mterry, yes he is, I'm just the little hand that tries to make the machinery work. [15:03] smspillaz: ;) [15:04] mterry: not completely sure what could have caused it, but unity didn't have any risky commits related to indicatorsssss [15:05] huh, why so many sss [15:05] -ssss [15:05] it looks like a gvariant data type [15:05] ssssasssiiiuubbbssssiiibbaassss [15:06] hehe [15:07] mterry, what about reverting 3156? does it fix the issue? [15:08] andyrock, I'm working on testing with a reversion. Just building now [15:08] but it should not be the problem [15:08] popey: do I need to fetch those drivers from somewhere ? [15:11] smspillaz: hmm? [15:12] smspillaz: oh, virtualbox? I'm using the 4.2.6 from upstream virtualbox.org website and the extensions that came with it [15:13] okay, I'll give thta a shot [15:14] andyrock: it shouldn't be the issue, no panel specific code was changed, right? [15:14] andyrock: just dash/launcher [15:15] sil2100, right [15:15] sil2100, mterry are we sure that the problem is unity? [15:15] mterry, and what indicators fail to show? [15:16] andyrock: all indicators fail to show, along with the appmenu [15:16] 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] Maybe its some dependency problem? ABI mismatch? In libindicator-dev ? [15:19] mterry, andyrock: since look at: http://bazaar.launchpad.net/~indicator-applet-developers/libindicator/trunk.13.04/revision/475 [15:20] Although I don't see any risky changes there [15:22] Since the libindicator versions used is 12.10.2daily13.02.15-0ubuntu1 [15:29] mterry, sil2100 confirmed the problem should be unity [15:29] me too [15:29] just now :) sil2100, stop being faster than me [15:29] am testing the reverted version [15:30] revision 3153 still has the problem [15:31] mterry, rev 3156 is not the problem btw [15:33] andyrock, yar, now I'm testing against 3152 [15:36] mterry, i get this running unity-panel-service: [15:37] http://paste.ubuntu.com/1658271/ [15:38] andyrock, ah... the indicators got multiarch'd accidentally [15:38] rather, not the indicators, but the panel service [15:38] Those changed to multiarch? [15:38] When did it change? [15:39] sil2100, they didn't, but the panel service is looking for them in a multiarch location [15:40] hence the bug [15:40] I wonder why then [15:41] dh 9? [15:43] doh, cycling at this hours to the park isn't friendly, too many cars on Friday evening [15:44] Cycling? === dandrader is now known as dandrader|afk [15:45] There's snow in Poland, I would freeze my hands off [15:45] ;) [15:45] heh, today, the temperature is 4/6° [15:45] so it's ok :) [15:45] hi didrocks [15:45] hey mterry [15:46] backlogging, one sec :) [15:46] hmm, unity is pulling that dir from indicator .pc file [15:46] So indicators package problem as suspected, hm? [15:46] oh, interesting [15:47] so built against latest indicator, the unity panel service is looking on a wrong location [15:47] mterry, pkg-config indicator3-0.4 --variable indicatordir [15:47] gives me [15:47] /usr/lib/x86_64-linux-gnu/indicators3/7/ [15:48] andyrock, that's wrong then [15:48] so it seems like libindicator3 after all [15:48] so the problem was not unity, just unity building using last libindi... [15:48] looks like it [15:48] *build unity using... [15:49] mterry: yeah, it's my code doing all the preparation in the ppa [15:50] 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] 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] didrocks, k [15:52] as for the indicators thing, rev 475 of libindicator seems to be the culprit. it's a big indicator rewrite [15:52] mterry: yeah, that and moving to dh9 [15:52] but the indicator itself is working [15:52] it's just the .pc file which seems guilty, right? [15:53] dh9 sets --libdir=multiarchpath, taht's why everything is messed up [15:53] didrocks, yeah. it uses libdir, but should be hardcoded [15:53] mterry: mind doing that? or cyphermox, maybe on Monday, we'll have daily finally :p [15:54] bregma: well, we can still use /usr/lib/x86_64-linux-gnu/libindicator3.so.7.0.0, this one is working :) [15:54] didrocks, I can do [15:54] thanks! [15:54] looking at why xpathselect isn't happy [15:54] first real cupstream2distro bug :) (I don't count the changelog with 2 names a bug :p) [15:55] didrocks: doing what? [15:55] xpathselect or libdir fixes? [15:55] cyphermox: read the backlog ;) (but mterry is handling it) [15:55] no libdir ;) [15:55] xpathselect, it seems to be in my code [15:55] ok [15:56] ah, yeah [15:56] I was looking at that, but couldn't understand what was up [15:56] this is weird, because we had that case a lot already [15:56] my only explanation is that the filterdir is empty [15:56] it seems to be finding the right versions numbers too [15:56] yep [15:57] it's just when diffing from the distro version [15:57] (the 3rd state) [15:57] which is telling "nothing interesting" [15:57] didrocks: mind adding the output of the version numbers it finds too? [15:57] that might help [15:58] cyphermox: it's not the issue, it's continuing after the version numbers ;) [15:58] oh, I know [15:58] cyphermox: but yeah, we can archive that [15:58] one sec, running the diff [15:58] but just getting to know that it was going far enough because the versions were fine was a little painful [15:58] I had to mess around with the code, because it tries to do funny things with launchpadlib creds [15:58] cyphermox: hum? the log is clear that it's then downloading from distro and making the diff? [15:59] didrocks: I like to start from the beginning to really understand what goes on ;) [15:59] ok, will add that [15:59] ohh wait [15:59] I remember something === dandrader|afk is now known as dandrader [16:01] maybe I'm misremembering, but : if not tip_bzr_rev > last_upstream_rev + num_uploads: [16:01] (in is_new_release_needed()) [16:01] tip_bzr_rev when I looked was 30 [16:01] last_upstream_rev was 28 [16:01] and num_uploads was 2 ;) [16:02] didrocks: that's in packagemanager.py [16:02] cyphermox: right [16:03] oh, I know [16:03] cyphermox: good catch, it's incremented, but it shouldn't if it's UNRELEASED [16:03] ah! [16:04] thought it had to do with that UNRELEASED entry, but I was looking at the wrong piece of code [16:04] the culpurit is: [16:04] # end of a changelog stenza (without getting the automated tag) means a manual upload [16:04] if new_changelog_regexp.match(line): [16:04] num_uploads += 1 [16:05] * didrocks opens a bug to remember having a test case for that [16:05] haha [16:05] I was looking at REV_STRING_FORMAT until I figured out what it was ;) [16:06] cyphermox: yeah, I tried to put all regexp in settings.py [16:06] didrocks: so, should be NEW_CHANGELOG_PATTERN = "^{} \((?!UNRELEASED)" ? [16:06] cyphermox: so that all detections and trickeries are matching the day we change the syntax [16:07] hum, why "(?" [16:07] wait, that's all wrong [16:07] didrocks: NEW_CHANGELOG_PATTERN = "^{} \(.*\) (?!UNRELEASED)" [16:07] (?! is a negative look-ahead [16:08] matches if UNRELEASED doesn't follow [16:08] there shouldn't be parens anywhere else so that regex is probably sufficient [16:08] https://code.launchpad.net/~mterry/libindicator/non-multiarch-indicatordir/+merge/148746 [16:09] that has the multiarch fix ^ [16:09] cyphermox: I need to check if this has side-effects [16:09] cyphermox: mind testing mterry's fix? :) [16:09] cyphermox: ok, let's put that in production next week anyway, I'll get a bunch of tests during the train trip [16:10] ^{} \([^)]*\) (?!UNRELEASED) [16:10] is safer I think [16:10] mterry: checking [16:10] mterry: looking nice [16:10] but why not multiarch? [16:10] * cyphermox reads backlog [16:10] mterry: set the commit message! [16:10] sil2100, shoot, thanks [16:11] damn commit message [16:11] cyphermox: mind commenting on https://bugs.launchpad.net/cupstream2distro/+bug/1126376? [16:11] Launchpad bug 1126376 in Canonical Upstream To Distro "new change undetected if only commit added code + a changelog (UNRELEASED)" [Undecided,New] [16:11] with your regexp [16:11] cyphermox, no multiarch for those directories just because of historical reasons [16:12] shouldn't we eventually migrate them to multiarch when possible? [16:13] cyphermox, yes, probably with a fallback to the non-multi-arch location [16:13] cyphermox, but that would be a touch of work and coordination [16:13] cyphermox, whereas right now I just want things back to normal to fix the build [16:13] yeah [16:13] cyphermox, I think this was an unintentional change [16:13] but I thought the indicators were installed to multiarch locations since a long time [16:14] 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] oh, I see [16:15] yeah, let's revert that but let's also try to migrate them properly soon [16:15] 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 === francisco is now known as Guest60673 [16:15] as each indicator gets built, it would migrate to the multiarch location, but old ones would still work [16:16] mterry: if we don't open a bug report for it, please put something in debian/changelog directly :) [16:16] didrocks, I'll open a bug [16:16] great! :) [16:16] didrocks, I opened a bug for the build problem today. But I'll also open a bug for the eventual migration [16:16] perfect :) [16:17] then we can relaunch indicator [16:17] and then unity [16:17] and maybe maybe [16:17] we'll have finally an unity release :) [16:17] yay [16:17] as it seems sil2100 fixes worked [16:17] testing the fix, I'll approve in a few minutes [16:17] cyphermox: just wait that the merge is linked to a bug before approving [16:21] didrocks, bug 1126385 [16:21] bug 1126385 in libindicator (Ubuntu) "Migrate to mulitarch indicators" [Undecided,New] https://launchpad.net/bugs/1126385 [16:21] cyphermox, ^ [16:21] cool [16:23] mterry: thanks! one linked to your branch and tested, cyphermox can approve I guess and let's get things kicked! ;) [16:24] didrocks, we still won't have unity release likely. I don't think the tests have been fixed yet [16:25] Plus, still super waiting for the ibus test fixes to be reviewd [16:26] mterry: are you sure? the dash failing are way fewer than before, isn't it? [16:27] mterry: what tests failing? The dash preview tests that broke the daily build yesterday got fixed hopefully [16:27] test_dash is -10 [16:27] sil2100: I can still see 5 of them [16:27] sil2100, oh that's right, that commit landed [16:27] on intel for instance [16:27] mterry: so we should be a bit better now, at least enough [16:27] didrocks: yes, there's still the problem with sometimes broken geometry in the dash [16:27] sil2100, let's hope so. Who's arm do I have to twist to approve your ibus branch? [16:28] arms? I thought mterry lived in USA and would handle that with guns :) [16:29] didrocks, I live in the wussy liberal part [16:29] 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] mterry: I won't say the educated part because tedg is around :) [16:29] I want thomi to take another look before it lands finally [16:30] mterry: we're just waiting for jenkins now! [16:30] sil2100, ah cool [16:30] * tedg hides [16:30] fginther: do you mind helping getting things in quickly? ^ [16:30] (easier to get the surprise shot that way) [16:30] :) [16:31] didrocks, reading the backlog [16:32] fginther: do you mind helping our dear jenkins friend merging https://code.launchpad.net/~mterry/libindicator/non-multiarch-indicatordir/+merge/148746? [16:32] (it's just that we have high hope there) [16:33] yep, I'll approve and kick off the job [16:33] fginther: excellent, thanks! [16:57] didrocks: bregma: anyone still actively maintains xorg-gtest? [16:57] cyphermox: since cnd left, I doubt about it [16:57] upstream, in Debian, or in Ubuntu? [16:57] that's what I feared ;) [16:57] bregma: any of the above [16:58] 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] the package in Ubuntu is up-to-date with the latest upstream [17:00] bregma: didn't smspillaz mentionned that a 0.8 exists? [17:00] ugh [17:00] he mentioned it, but I think he was confused [17:00] ok, that's why I tought nobody actively maintained it, because of that :) [17:01] good to know you are trying to keep it up to date! :) [17:01] ok so we're depending on libgtest-dev in libxorg-gtest-dev already [17:01] upstream: http://cgit.freedesktop.org/xorg/test/xorg-gtest/ [17:01] bregma: yeah, seems it's pretty fresh :) [17:02] I think I'll fix things up in a few patches and propose them upstream [17:02] no objections from me [17:02] bregma, didrocks: cnd seems still active on it, http://cgit.freedesktop.org/~cndougla/xorg-gtest [17:03] that's almost a year old [17:03] yeah, that's what I wanted to say :) [17:04] bregma, didrocks: ignore me, I didn't update to 2013 yet it seems :p [17:04] * didrocks sudo seb128 update [17:04] didrocks, sudo seb128 ntpdate ouais :p [17:04] ahah ;) === dandrader_ is now known as dandrader|afk [17:19] fginther: are you sure you pressed the right button? https://code.launchpad.net/~mterry/libindicator/non-multiarch-indicatordir/+merge/148746 :) [17:19] seeing the -ci build didn't took a long time [17:19] but the actual merge seems to [17:20] didrocks, yes i screwed up initially, it's merging as we speak [17:20] ok, thanks fginther :) [17:20] ah, done! [17:20] sweet! :) [17:21] 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] didrocks, I probably won't. I'm only supposed to be a half day today [17:22]