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