[03:40] Good morning [04:36] g'daaay [05:46] good morning [05:46] bonjour didrocks [05:47] bonjour pitti, comment ça va? [05:48] didrocks: ça va bien, merci ! Je me suis levé tôt aujourd'hui, avec ma femme [05:48] didrocks: et toi ? [05:49] pitti: ça va bien, on dirait que le temps n'est pas si horrible que ça, un peu de soleil malgré les nuages :) [05:49] ooh! [05:50] didrocks: ping [05:50] didrocks: enfin, tu vas avoir l'été ? :-) [05:50] pitti: il faut croire, au moins aujourd'hui :) [05:50] hey veebers! [05:51] veebers: thanks for your MP on the testsuite listing :) [05:51] how goes it didrocks? [05:51] didrocks: heh no problem, hopefully it's helpful [05:51] veebers: I'm doing good, thanks. Yourself? [05:51] didrocks: hmm, had a day scratching my head WRT to a couple of the autopilot functional tests failing in the jenkins job [05:52] didrocks: which is why I bother you now, it appears that with a i386 install the tests fail, using a amd64 install they pass no problems [05:52] veebers: interesting, normally, it's more the other way around :) [05:52] veebers: do you have a link? [05:53] (this is WRT to the email that sil2100 sent) [05:53] ah, just got to it (60 emails in the morning, can't be that efficient) [05:53] one sec! [05:53] didrocks: I don't have a link to the passing job as there is not one, I'm manually manipulating the machine, but there is a link to the failing one in the email :-) [05:53] ah ok, those ones [05:53] didrocks: only 60? [05:53] :P [05:54] thomi: in inbox :p [05:54] didrocks: right [05:54] then, I don't count the bugs, MP, ML… :p [05:54] didrocks: me neither :P [05:54] heh ;) [05:54] ok, the good thing is that it's reproducible everyday on both intel and ait [05:54] ati* [05:54] so, if I bzr branch lp:autopilot [05:54] and run the tests [05:55] I won't see those on my amd64? [05:55] didrocks: the entire autopilot test suite passes for both veebers and myself, and on an amd64 machine veebers has going in the QA lab, and on a VM [05:56] didrocks: None of us have an i386-installed machine, so it took us a while to think about trying that [05:56] thomi: can I run tip trunk in my session without being scared? [05:56] didrocks: yes, it's fine [05:56] didrocks: yep [05:56] didrocks: trust me :P [05:56] oh, thomi you bet me to it :) [05:56] * thomi quickly pushes some code to trunk :) [05:56] ahah :p [05:57] thomi: veebers: bin/autopilot run autopilot/tests/ ? [05:57] didrocks: I'm about to try a i386 VM, but waiting for iso [05:57] bin/autopilot run autopilot.tests [05:57] oh right [05:57] didrocks: autopilot run -v autopilot.tests.functional.test_input_stack.TouchTests [05:57] or that [05:57] didrocks: that is for 2 of the 3 failing [05:57] but I guess you want *all the tests* [05:57] yeah, I prefer to see all the tests, if this has an impact :) [05:58] (running btw) [05:58] didrocks, thomi I'll be back in a little bit. Need to do the grocery shop and have tea :-) [05:59] veebers: sure, enjoy! [05:59] * veebers hates the supermarket [05:59] :-P [05:59] don't enjoy then :p [05:59] didrocks: cheers [05:59] o_0 [06:04] thomi: ok, I have a lot of failures, but I think it's not related to that :) [06:04] thomi: some surely due to autopilot-gtk not being installed I guess [06:04] didrocks: ahhh, you're missing some deps then [06:04] and a lot of getcwd() failing [06:05] interesting [06:05] it rmed my trunk! [06:05] zomg :p [06:05] didrocks: check out the deps listed in debian/control for the python-autopilot-tests [06:05] packahe [06:05] maybe /tmp/autopilot wasn't the right place to put it :) [06:06] didrocks: that should work fine [06:07] thomi: weird that the directory was removed once the test finishes though :p [06:07] didrocks: really? [06:07] yeah [06:07] I bzr branch lp:autopilot in /tmp [06:07] cd /tmp [06:07] bin/autopilot … [06:07] and /tmp/autopilot was removed [06:07] hence all the getcwd() error I guess [06:07] thomi: maybe you use that directory somewhere as a temporary placeholder? [06:08] didrocks: ahhhhhh [06:08] didrocks: yes, now that I think about it [06:08] :p [06:08] didrocks: file a bug if you like [06:08] thomi: with pleasure! :-) [06:09] :) [06:09] thomi: ok, I don't have python-evdev [06:09] let me see if it's in the ppa [06:09] * didrocks steals [06:09] should be [06:10] thomi: I'm getting now UInput: UInputError('"/dev/uinput" cannot be opened for writing',) [06:11] (on the autopilot.tests.functional.test_input_stack.TouchTests) [06:11] which is still different from what the error was on the tests [06:11] didrocks: on sec [06:11] just in a call [06:12] sure :) [06:12] * didrocks opens the bug meanwhile [06:13] thomi: bug #1182755 FYI [06:13] Launchpad bug 1182755 in Autopilot "autopilot removes /tmp/autopilot while running its testsuite" [Undecided,New] https://launchpad.net/bugs/1182755 [06:14] didrocks: so to fix your permissions issue, you can build the package and install python-autopilot [06:15] didrocks: it will add you to the autopilot group [06:15] didrocks: which will give you the permissions you need [06:15] thomi: ah ok [06:15] doing that now [06:15] didrocks: or you can do it manually I guess [06:15] thomi: hum, let's have the autopilot package installed anyway [06:22] thomi: ok, logging out and back now that I have all the deps installed [06:22] \o/ [06:24] thomi: keep getting: [06:24] 08:23:56.041 WARNING __init__:185 - Caught exception while searching for autopilot interface: 'DBusException("Could not get PID of name 'org.freedesktop.DBus': no such name",)' [06:24] (running autopilot run -v autopilot.tests.functional.test_input_stack.TouchTests) [06:24] with the installed tip trunk of autopilot, and installed tests [06:27] didrocks: and the test fails? [06:28] thomi: yep, with an unsurprising RuntimeError: Unable to find Autopilot interface. [06:28] didrocks: I'm afraid I need to go to dinner, we have guests, but perhaps you can email me the details? I can assure you that the tests all pass for me... I suspect there's some odd library issue going on [06:28] but that seems really odd. veebers tested with a fresh VM and it worked perfectly [06:29] thomi: well, it was just to double confirm the failure on we have while tests are executing [06:29] thomi: you will continue with an i386 machine I guess? [06:29] thomi: basically, this is what today is blocking all the stacks to go to saucy [06:29] (touch included) [06:29] no pressure ;) [06:30] didrocks: if it's that important, just disable those three tests. We know they pass for amd64, and I'm pretty confident in the quality of the code. [06:30] thomi: ok, we can do that, indeed [06:30] or have a trigger of 4 tests failing [06:30] didrocks: probably the best idea at the moment, especially since I'm kinda busy these days [06:30] didrocks: 3 tests [06:30] thomi: no, 4 ;) [06:31] didrocks: we already fixed one of the failures yesterday, but after your last run was triggered [06:31] ah ok [06:31] didrocks: so we're down to 3 [06:31] thomi: so I'll put the trigger to 3 [06:31] so that we don't disable them in trunk [06:31] thomi: but then, we'll need to tackle that I guess [06:31] ok [06:31] anyway, I gotta go. Talk to you later [06:31] thomi: enjoy your dinner! [06:48] good morning [06:48] hey jibel ! [06:48] salut didrocks ! [06:54] jibel: jenkins isn't really happy right now :( [06:54] jibel: all the prepare jobs are red (even if the upload to the ppa was successful) [06:54] /var/lib/jenkins/jobs/cu2d-oif-head-1.1prepare-frame/builds/2013-05-22_02-01-23/archive is empty though [06:55] so that's why have: [06:55] Archiving artifacts [06:55] ERROR: No artifacts found that match the file pattern "*xml". Configuration error? [06:55] ERROR: '*xml' doesn't match anything [06:56] the xml are there though in the workspace: /var/lib/jenkins/cu2d/work/head/oif/ [06:56] pitti: bon ben voilà… c'est plus l'été ici :( [06:57] * didrocks will ask for refunding from the weather master [07:01] jenkins also seemed to be down earlier [07:04] Mirv: ah, let me try to rerun a prepare then [07:05] Mirv: no, still the same issue :/ [07:05] ok :( [07:06] didrocks, looking [07:06] Mirv: since the sprint, we are quite unlucky, it was really stable beforehand [07:17] didrocks, it doesn't make sense workspace is set to WORKSPACE=/var/lib/jenkins/jobs/jenkins-autocheck/workspace while it should be /var/lib/jenkins/jobs/cu2d-oif-head-1.1prepare-frame/workspace [07:17] or the name of the project [07:18] jibel: hum, maybe that's when we relaunch prepare directly [07:18] jibel: as we inherit fro m [07:18] from the parent* [07:19] jibel: one sec, trying the parent [07:19] hum still WORKSPACE=/var/lib/jenkins/jobs/jenkins-autocheck/workspace [07:20] jibel: waitonstack is in the right ws though [07:20] Building on master in workspace /var/lib/jenkins/jobs/cu2d-oif-head-0waitonstacks/workspace [07:20] ah that doesn't mean anything [07:20] Building on master in workspace /var/lib/jenkins/jobs/cu2d-oif-head-1.1prepare-frame/workspace [07:20] but waitonstack didn't fail, so I think the relative dirs were ok [07:22] WORKSPACE=/var/lib/jenkins/jobs/jenkins-autocheck/workspace [07:22] jibel: for waitonstack ^ [07:24] hey desktopers [07:24] salut seb128! [07:25] didrocks, this is a problem with the master node, even the most simple job inherit from this workspace [07:26] jibel: some workspace root directory? [07:27] didrocks, my guess would be that someone restarted jenkins with this variable set in his environment [07:27] but that's just a guess [07:27] jibel: oh, and that override everything? Mirv mentionned that jenkins was down earlier [07:29] didrocks: jibel it seemed like down at least, but I cannot be sure if it was VPN or jenkins itself [07:29] didrocks, I'll restart master with a clean env, do you need to wait for webapp-head? [07:30] jibel: I have no hope for webapp, so kill please :) [07:53] didrocks, jibel: OOI, how's otto behaving in the DC? [07:54] pitti: we are more fighting with jenkins issues (env not being good) for now… [07:55] pitti, we didn't test much yesterday becasue the lab was down most of the day. But we made good progress on the integration with autopilot [07:56] yeah, I just looked at the most recent commits (and did some README fixes) [07:56] looking great! [07:56] nice :) [07:59] pitti, salut, ça va ? [07:59] seb128: bonjour Monsieur ! ça va bien, et toi ? [07:59] pitti, ça va bien merci ;-) [07:59] I'm happy that I didn't get bombarded with regression reports from udev so far :) [07:59] I wished I could finish the autopilot side this morning, but once again didrocks killed my morning ;) [07:59] jibel: you killed mine as well [07:59] :p [08:00] TBH, since the sprint, the jenkins machine is really horrible, we lost of lot of runs and hours… [08:00] pitti, hehe, good job! [08:02] guten morgen [08:07] Laney, good morning [08:07] hey [08:08] apparently Skype fixed the bug I reported in the new release ... probably didn't need to workaround it in glib yesterday [08:08] ho hum [08:12] Laney, nice, we can drop it in the next upload then [08:12] yep [09:10] attente: ping! [09:17] good morning [09:21] ricotz: p11-kit goes depwait on libtasn1-6-dev === vrruiz_ is now known as rvr [09:32] hi Laney, how are you? [09:33] hey chrisccoulson [09:33] I'm on cup of tea #4 ... getting there ;-) [09:33] how are you? [09:34] * czajkowski nicks Laney bucket of tea [09:34] Laney, good thanks. i'm looking forward to the weekend so I can open a bottle of AB:13 :) [09:34] :O [09:35] I shouldn't ... don't ... buy ... arghgosdihgsoih [09:36] heh [09:36] I wonder if you can buy bottles from the pubs [09:36] that would be more cost effective [09:37] it's about 10 minutes from here ... [09:37] yeah, the delivery costs really suck [09:37] we have a local off-license who normally gets them in (http://www.stirchleywines.co.uk/) [09:39] even the AB? [09:39] hey chrisccoulson [09:39] Laney, yeah, they still have some of the older ones in stock too [09:39] hi seb128 :) [09:39] wow [09:40] Laney, ah sorry, libtasn1-6 needs to be MIRed :\ [09:40] our beer shop is pretty CAMRA so I doubt you'd see any brewdog there ever :P [09:40] ricotz: well, 1-3 is in main so maybe not [09:40] https://launchpad.net/ubuntu/+source/libtasn1-6 [09:40] but perhaps we could avoid having both in main [09:40] Laney, ah, ok [09:41] Laney, see, there are *some* advantages to living in the west midlands [09:41] well, 1 [09:41] :) [09:41] bah [09:41] I checked it out a little bit and gnutls (one of the rdeps) was reverted back to 1-3 in Debian [09:41] wifi reconnect [09:41] should check out why [09:41] ricotz: want to investigate? [09:41] chrisccoulson, hey ;-) (not sure it went through before) [09:41] I also checked and p11-kit seems to be OK against 1-3 [09:41] hi seb128 :) [09:42] Laney, will testbuild it again 1-3 [09:42] grand [09:43] chrisccoulson, did you see that ted asked you for small stylistic changes for your dbusmenu fix? [09:43] seb128, yeah, i saw that [09:45] seb128, it's great being able to change my network configuration in the morning and not have to restart nm-applet :) [09:46] chrisccoulson, did it start doing it more frequently recently for you? [09:46] nobody was able to reproduce that around the precise time [09:47] seb128, yes, but i suspect that is to do with the explosion of wifi networks nearby (it runs out of ID's faster) [09:47] right [09:48] I'm glad you figured it out anyway [09:48] we should get that in and then backport to precise [09:48] with the 2 leak fixes you made earlier [09:48] yeah, would be good :) [09:48] chrisccoulson, I guess you never managed to find time to write testcases for those? [09:48] not yet. it probably shouldn't be too hard though [09:49] chrisccoulson, step 1, update that MR to address ted's comment so we can get the fix in saucy [09:49] then we can discuss SRUs ;-) [09:54] Laney, gcr/keyring related functions working as expected -- http://paste.debian.net/plain/5709 [09:55] ta [09:55] just looking at clutter-1.0 first [09:56] ricotz: can't that be pushed to exp? [09:56] (clutter) [09:56] no problem, thanks [09:56] Laney, 1.14.4 yes [09:56] want to update it in svn? I can sponsor there [09:57] Laney, hmm, ok [09:57] seems like a straightforward update [09:57] cheers === alan_g is now known as alan_g|tea === ritz_ is now known as ritz|away === alan_g|tea is now known as alan_g === MacSlow is now known as MacSlow|lunch [11:37] sil2100: pong [11:45] attente: hello, can I poke you in 15 minutes? [11:46] sure [11:52] attente: ok, free again [11:53] attente: so, I actually had a question - when I unisntall appmenu-gtk3 and use unity-gtk3-module instead, I actually get some errors in gedit [11:53] `menu_proxy_module_load': gedit: undefined symbol: menu_proxy_module_load [11:53] (gedit:5089): Gtk-WARNING **: Failed to load type module: (null) [11:53] The appmenu is there, but all entries seem to be grayed out [11:53] Am I missing some package/patch? [11:58] sil2100, you might need http://bazaar.launchpad.net/~indicator-applet-developers/indicator-appmenu/trunk.13.10/revision/238 [11:58] sil2100, what version of indicator-appmenu do you use? [11:59] Ah, let me check [12:00] 13.01.0daily13.05.02.1ubuntu.unity.next-0ubuntu1 <- old one indeed === alan_g is now known as alan_g|lunch [12:01] yeah, seb128's right [12:02] the warning is probably because UBUNTU_MENUPROXY is still set to the old appmenu.so [12:03] sil2100, iirc that update would fix the inactive items === greyback is now known as greyback|lunch === MacSlow|lunch is now known as MacSlow [12:12] any other still getting the -ati machine brokenness in check phase? [12:14] not seeing the same elsewhere, but getting "UTAH timeout: Timeout (3600) occurred for install complete message." on SDK [12:24] seb128, attente: thanks guys [12:25] sil2100, does it work with the new appmenu? === greyback|lunch is now known as greyback === dpm_ is now known as dpm-uow === dpm is now known as dpm-laptop === dpm-uow is now known as dpm === alan_g|lunch is now known as alan_g [13:41] didrocks, you had said to remove the -check for webcred after redeploying, how do i do that? [13:42] kenvandine: just click on the job [13:42] kenvandine: then, on the left, you have a delete job option [13:43] didrocks, i don' [13:43] t [13:43] oh [13:43] kenvandine: are you logged in? [13:43] i'm not logged in anymore... [13:43] :) [13:44] i have "Delete Project" [13:44] yep, that's the one [13:44] woot [13:44] thx [13:45] is something wrong with the public jenkins? [13:45] Please wait while Jenkins is getting ready to work.... [13:46] kenvandine: yw :) [13:47] didrocks: still not merged :< [13:48] sil2100: did you repoke mmrazik? [13:48] didrocks: I poked Martin, he said that he unblocked it and put on the queue, but it's merging over 4 hours now [13:48] sil2100: and repoked? [13:48] didrocks: I'll repoke fginther ^ [13:48] yeah, thanks! [13:48] Mirv's one is merged [13:49] fginther: poke, could maybe you take a look if it's still building, or is it broken? [13:49] Mirv: waiting for jenkins to restart and then I'll do the rebuild for sdk [13:49] sil2100, didrocks it's still running, about 30 minutes left [13:49] fginther: after 4h? :/ [13:50] sounds like it's not armhf only the issue ;) [13:50] Maybe the merger was busy ;p [13:50] kenvandine: webappsappsappsapps :) [13:50] thanks! [13:50] np [13:51] kenvandine: I see that some are rereleasing like -youtube [13:51] kenvandine: without any new content [13:52] kenvandine: it means that building the source package is creating some diff with trunk [13:52] kenvandine: do you mind having a look? [13:52] sil2100, didrocks, :-( [13:52] same for gmail, facebookmessenger [13:52] kenvandine: I think go on all the ones that were published and when there is no commit message, it means there is something that needs to be fixed [13:53] humm... i thought prepare prevented that? [13:55] kenvandine: yeah, if the source package doesn't have any diff with trunk (apart from .bzr) [13:55] kenvandine: as it's making a diff to compare [13:55] so there must have been some diff there? [13:55] yeah, like some .log [13:55] or whatever [13:55] oh [13:56] i'll look at one of them [13:57] kenvandine: thanks, FYI the diff I'm doing is: [13:57] diffinstance = subprocess.Popen(['diff', '-Nrup', '.', dest_version_source], stdout=subprocess.PIPE) [13:57] filterinstance = subprocess.Popen(['filterdiff', '--clean', '-x', '*po', '-x', '*pot', '-x', '*local-options'], stdin=diffinstance.stdout, stdout=subprocess.PIPE) [13:57] lsdiffinstance = subprocess.Popen(['lsdiff'], stdin=filterinstance.stdout, stdout=subprocess.PIPE) [13:57] (relevant_changes, err) = subprocess.Popen(['grep', '-v', '.bzr'], stdin=lsdiffinstance.stdout, stdout=subprocess.PIPE).communicate() [14:05] didrocks, i looked at gmail [14:05] there was a translations merge [14:05] all the .po files were changed [14:05] kenvandine: hum, see my filterdiff ^ [14:05] yeah [14:05] that is the only change [14:05] kenvandine: you did try to run the command? [14:06] ok, i'll try that [14:06] kenvandine: remember to bzr revert && bzr uncommit the last commit :) [14:07] as the generated one wasn't there [14:09] didrocks, weird... i ran that and it returns nothing [14:10] so prepare shouldn't have prepared it... [14:10] kenvandine: what did you run exactly? can you paste the command? [14:10] $ diff -Nrup . ../unity-webapps-gmail-2.4.16daily13.05.17/ | filterdiff --clean -x '*po' -x '*pot' -x '*local-options' | lsdiff | grep -v ".bzr" [14:10] sigh [14:10] ./debian/files [14:10] so yeah [14:10] there is a diff [14:10] kenvandine: ^ [14:10] oh wait... if there is a commit message you still prepare right? [14:11] kenvandine: no, it's only the diff deciding [14:11] dobey: ? [14:11] wtf does libpeas have python and python3 as separate loaders for? it should just have a --with-python3 configure option or something, to specify whether to use python3 or python2 for the loader [14:11] oh... i wasn't doing it from bzr [14:11] kenvandine: diffing the same folder twice? :p [14:11] what are you diffing it with unity-webapps-gmail-2.4.16daily13.05.17 ? [14:12] trunk? [14:12] i was diffing the commit that was in the changelog [14:12] with latest reverted commit as we are in daily release, so before the change in changelog is done) [14:12] yeah [14:12] i reverted that and did a bzr diff -c 50 [14:12] with the filterdiff [14:12] dobey: argh, not fun :( [14:12] ah ;) [14:12] didrocks, so the latest in the ppa is 13.05.21.1 [14:12] kenvandine: no, you want to diff trunk and what's in the distro :) [14:12] not 05.17 [14:13] ah, right what was published [14:13] kenvandine: yeah, but I'm diffing with distro [14:13] the destination :) [14:13] (or next for instance) [14:14] didrocks: tell me about it, since i have a plug-in that's written in python, and rhythmbox git has switched to 'python3' as the loader, and there's no way to tell which one i should use (plus i'd need to do it at runtime, which is basically impossible, since there's no way to know which one to use before then, and the plug-in won't run unless you pick the right one) [14:14] didrocks, 2.4.16daily13.05.21.1-0ubuntu1 was the previous version in saucy [14:15] kenvandine: are you sure? ;) https://launchpad.net/ubuntu/saucy/+source/unity-webapps-gmail [14:15] http://launchpadlibrarian.net/140436635/unity-webapps-gmail_2.4.16daily13.05.21.1-0ubuntu1_2.4.16daily13.05.22-0ubuntu1.diff.gz [14:15] there is a changes file for it [14:15] dobey: that's why I don't want to do bindings :p [14:15] which is weird [14:15] there are two changes files for today's version [14:16] kenvandine: it's been never published to saucy though, you should get that from a ppa ;) [14:16] didrocks: eh? [14:16] kenvandine: see my link, last one is .17 [14:16] yeah [14:16] oh... so it was in saucy-proposed i guess [14:16] I don't think so, I don't even see it in -changes [14:16] regardless... why doesn't that file show in the diff? [14:17] https://launchpad.net/ubuntu/+source/unity-webapps-gmail/2.4.16daily13.05.22-0ubuntu1 [14:17] look there [14:17] kenvandine: because you compare tarball to tarball [14:17] diff from 2.4.16daily13.05.21.1-0ubuntu1 to 2.4.16daily13.05.22-0ubuntu1 [14:17] kenvandine: not tarball to trunk [14:17] so if the file is generated/removed from trunk, it will be removed in both diff === m_conley_away is now known as m_conley [14:18]