[00:00] <slangasek> the perl upgrade was on Mar 4... seems unlikely to have no packages with debconf questions from the 4th until the 20th, though I guess it's possible
[00:40] <doko>  o console-setup-freebsd-charmaps-udeb console-setup-freebsd-fonts-udeb console-setup-linux-charmaps-udeb console-setup-linux-fonts-udeb console-setup-pc-ekbd{console-setup}
[00:40] <doko> cjwatson, is there anything needed in main?
[00:41] <doko> ohh, I see python3-launchpadlib. should we keep that in main?
[03:55] <slangasek> doko_: console-setup-linux-charmaps-udeb console-setup-linux-fonts-udeb console-setup-pc-ekbd belong in main, the freebsd ones are irrelevant
[04:06] <infinity> slangasek: I have a couple of bug reports about that debconf failure, but hadn't yet seen it locally or managed to reproduce.  If it only happens under update-manager, that's a hint (though, an annoying hint...)
[10:28] <smb> Not sure this isn't a wrong assumption on my part, but I just noticed that on the 14.04.2 amd64 server iso pool/main/l/linux looks like this: http://paste.ubuntu.com/10667920/ Since the installer kernel is a 3.16, should there be not 3.16 udebs? Also the md and multipath modules seem to be over-eagerly supplied...
[10:48] <mparillo> stgraber: I am noticing some obsolete test cases for Kubuntu. https://bugs.launchpad.net/ubuntu-manual-tests/+bug/1425193 Riddell sent me your way. Would I be able to remove the obsolete Kubuntu test cases and edit them? You can find me on Launchpad at marco-parillo (first e-mail), if I am not on-line here.
[11:50] <elfy> mparillo: re manual testcase, probably better to just create new testcases
[11:51] <elfy> as far as removing them - anyone in kubuntu release team should have perms to remove old testcase from the list
[11:54] <elfy> not sure who's about interested in beta2 images but bug 1435714
[11:55] <elfy> I assume that'll affect everyone - it certainly affects Xubuntu, Ubuntu and Mate
[12:06] <flexiondotorg> http://launchpad.net/bugs/1432285
[12:07] <Odd_Bloke> I can see cloud-init apparently being accepted in http://people.canonical.com/~ubuntu-archive/proposed-migration/trusty/update_output.txt; did it miss migrating before the beta freeze (or is there something else happening)?
[12:08] <cjwatson> the beta freeze should have no effect on trusty
[12:08] <cjwatson> stable release migrations are always manual, though
[12:08] <cjwatson> proposed-migration runs in a dry-run mode there
[12:09] <cjwatson> it merely serves to provide input to http://people.canonical.com/~ubuntu-archive/pending-sru.html
[12:15] <Odd_Bloke> Aha, I thought there was a page I was missing.
[12:15] <Odd_Bloke> Thanks!
[12:20] <Odd_Bloke> *some documentation reading later* Could I get an AA to promote cloud-init in precise, trusty and utopic?
[12:37] <mparillo> Thank you elfy. Apparantly, there is no separate Kubuntu Release Team. Do you know how I can apply to join the Ubuntu release team?
[13:12] <flexiondotorg> elfy, The eject issue is critical. On EFI system you'll enter and almost inescapable boot loop and the end of the install.
[13:13] <flexiondotorg> elfy, <davmor2> flexiondotorg: the other nice issue is if you are on a system with UEFI there is no boot from HD option in the menu so you are stuck in a menu/boot loop where you cant remove the dvd, you can't can't eject the dvd and you can't boot to another device so you eject the dvd, bit of an issue :)
[13:14] <davmor2> added it as a comment to the bug will be filing another for the menu to have a boot from hdd
[13:18] <flexiondotorg> davmor2, Thanks.
[13:40] <doko> slangasek, cjwatson: demoted the freebsd ones, I assume the other need seeding. but then I noticed that the other seeded console-* packages don't exist anymore
[13:40] <doko> also, there are still ttf-* packages seeded, instead of fonts-*
[13:41] <cjwatson> feel free to sort this out, I wasn't involved in the latest console-setup merge
[13:41] <doko> ok
[13:42] <cjwatson> and ttf- => fonts- has been a gradual process for ages
[13:49] <infinity> So, I hear everything failed miserably overnight?
[13:52] <flexiondotorg> infinity, Hi
[13:52] <flexiondotorg> infinity, http://launchpad.net/bugs/1435714
[13:53] <infinity> cyphermox: ^
[13:54] <infinity> cyphermox: Can you hunt this down?  Might relate to the console-setup package split?
[13:54] <infinity> flexiondotorg: Going to assume from the Xubuntu and MATE mentions that pretty much every one is seeing this bug?
[13:55] <flexiondotorg> infinity, I know you're catching up. When you've had a coffee and what have you could you do some magic to make the PowerPC build for Ubuntu MATE appear in the Beta 2 tracker please?
[13:55] <davmor2> infinity, jibel: who adds netboot?
[13:56] <infinity> flexiondotorg: That might need stgraber, I'm less familiar with that part of the "UI" (and I use that term loosely).
[13:56] <jibel> davmor2, I'll do
[13:56] <infinity> flexiondotorg: Oh, wait.  Maybe I found it.
[13:56] <jibel> and upgrade tests too
[13:57] <davmor2> infinity: the scariest bug so far is https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1432285
[13:57] <infinity> flexiondotorg: Okay, it's added to the manifest, won't show up until the next rebuild unless someone manually fiddles a bit.
[13:57] <flexiondotorg> infinity, Thank you.
[13:58] <davmor2> infinity: and of course that's all cyphermox 's fault ;)
[13:59] <infinity> davmor2: He's the new kid, he gets to take blame^Wresponsibility for everything.
[14:00] <flexiondotorg> infinity, If you get the time can you update the ubuntu-mate-meta package and push it into the repo?
[14:00] <infinity> flexiondotorg: What did you change this time?
[14:00] <flexiondotorg> infinity, Nothing.
[14:00] <davmor2> infinity: I told him straight you know that means that anything to do with installs now is all your fault when he took the job ;)
[14:00] <flexiondotorg> Not seeing the new version.
[14:00] <infinity> flexiondotorg: Then there's nothing to upload?
[14:01] <infinity> flexiondotorg: Or you missed all my nick hilights to you last night? :P
[14:01] <flexiondotorg> infinity, Was waiting for the updated ubiquity-slideshow-ubuntu to hit the repos so the meta package update could "see" it.
[14:01] <infinity> flexiondotorg: ship and ship-live don't affect metapackages, so nothing to rebuild.  They just affect how the /pool/ on CDs is built.
[14:01] <flexiondotorg> infinity, I did :( Nothing in my bouncer.
[14:01] <flexiondotorg> infinity, Ah. OK, great.
[14:01] <infinity> flexiondotorg: Furthermore, I reverted your seed change, since oem-config/ubiquity has no idea how to install a non-standard slideshow.
[14:02] <flexiondotorg> infinity, Sob!
[14:02] <infinity> flexiondotorg: The part where no other flavour has a special slideshow might have been a hint. :)
[14:02] <flexiondotorg> infinity, I just thought they were lazy ;)
[14:02] <infinity> flexiondotorg: So, patches welcome, and happy to work with you on fixing that, but I figured for this week, you're better off with the generic slideshow than a broken CD. :P
[14:03] <flexiondotorg> infinity, UNderstood. I'll add slideshow patches to my 15.10 work list.
[14:03] <flexiondotorg> infinity, I'll update the seeds to not include any slideshow. It works fine without one.
[14:05] <micahg> is there a link for the Xubuntu image failure that I could help with
[14:06] <infinity> micahg: I think the problem was on our end, not yours.  I need to wake up enough to say that with certainty, though. :P
[14:06] <cyphermox> infinity: could be; could also be related to when doko asked what packages should be in main yesterday
[14:07] <micahg> infinity: ok, let me know if I can help then, thanks
[14:07] <infinity> cyphermox: Well, having them in main won't magically get them installed.
[14:07] <cyphermox> no
[14:07] <infinity> cyphermox: So, if those packages are actually needed, maybe they should be depended on by... something.
[14:08] <infinity> cyphermox: Anyhow, if you could figure out what's broken, that would be great.  It might not be the split at all, that could be a red herring, but it seems plausible.
[14:08] <smb> infinity, Did you see my earlier question while looking through srollback? Or let me repeat... wondering whether I am turning mad... ok madder than usual...
[14:08] <smb> Not sure this isn't a wrong assumption on my part, but I just noticed that on the 14.04.2 amd64 server iso pool/main/l/linux looks like this: http://paste.ubuntu.com/10667920/ Since the installer kernel is a 3.16, should there be not 3.16 udebs? Also the md and multipath modules seem to be over-eagerly supplied...
[14:09] <cyphermox> infinity: indeed
[14:09] <cyphermox> infinity: just moving this to my desktop right now
[14:09] <cyphermox> "tada!"
[14:10] <infinity> smb: The overeager thing is a bug I intentionally ignored due to time constraints, but the other bit seems rather wrong... Lemme look.
[14:11] <infinity> smb: Oh, and indeed, just overeager in both cases.
[14:11] <smb> infinity, Ok thanks. I just noticed while trying simulated multipathing and the magic runes did seem to do nothing
[14:11] <infinity> smb: pool/main/l/linux-lts-utopic has the right bits.
[14:11] <smb> oh duh...
[14:12] <infinity> smb: It's absolutely a bug that there are 3.13 bits on the ISO, but that's really just cosmetic (and a bit of bloat), it shouldn't be causing harm.
[14:13] <cyphermox> flexiondotorg: downloading the image. it seems kind of slow, so as soon as it's done I'll get on to fixing the keyboard.
[14:13] <smb> infinity, ok. Yeah... got me a bit confused... hm...
[14:15] <flexiondotorg> cyphermox, All flavours, including Ubuntu proper, are affected.
[14:15] <flexiondotorg> cyphermox, So, If you have a recent Ubuntu image to zsync you can use that.
[14:16] <cyphermox> yup, I got that
[14:16] <flexiondotorg> cyphermox, k
[14:16] <infinity> smb: cyphermox and an IBMer did a bunch of work on multipath in vivid, it's possible some of that needs backporting.
[14:17] <cyphermox> not just possible :)
[14:17] <infinity> smb: I was under the impression that multipath was working in trusty, but maybe I haven't tested it since precise, and no one else cared to. :P
[14:17] <cyphermox> but that wouldn't change the packages being overeagerly included
[14:17] <smb> infinity, That is quite likely... I neither did until now
[14:17] <infinity> cyphermox: No, the overeager inclusion is a seed bug I was just too time-constrained to fix.
[14:17] <cyphermox> ok
[14:18] <cyphermox> well, if you want to quickly test multipath on trusty, etc. I can share a quick script to set things up in qemu
[14:19] <smb> So with the caveat that I did something else wrong... which I would not rule out ... It seemed that adding disk-detect/multipath/enable=true did not cause the same as in did in Vivid...
[14:19] <smb> cyphermox, I am just looking at that
[14:22] <cyphermox> smb: http://bazaar.launchpad.net/~mathieu-tl/+junk/vm/files
[14:22] <cyphermox> multipath.sh sets up qemu for amd64 with two multipath "controllers"
[14:22] <smb> cyphermox, One thing which seems to be the same in V and T is that maybe we should tweak the default getuid arguments a bit to use -u (replace space by underscore)
[14:22] <cyphermox> smb: I've just been discussing that, not a bad idea
[14:23] <smb> cyphermox, I guess you have been exposed to the same IBM bug report about multipath. :)
[14:24] <cyphermox> I probably was
[14:25] <cyphermox> still working on some variant of that, actually, checking to make sure we really properly nailed the lock issue
[14:26] <smb> cyphermox, I had a feeling that having udev rules causes everything to jump at the same disks ... but then with V there is also systemd and I can find none of the dear logs I am used to
[14:29] <cyphermox> ok
[14:36] <smb> cyphermox, so the question probably is: who whom we know, knows s**t about udev and its hiding in systemd... I guessed pi tti might be the latter and try to have a chat with him. Not sure about the former
[14:36] <infinity> Bleh, looks like I'll have to do some of those rebuilds by hand to unwedge iso.qa's brain.
[14:39] <cyphermox> smb: err, what for?
[14:40] <elfy> infinity: generally if I see something like the keyboard setup missing I check at least Ubuntu as well as my own - just for the future
[14:41] <cyphermox> smb: https://launchpad.net/ubuntu/+source/multipath-tools/0.4.9-3ubuntu11 should be fixing at least part of the problem with udev
[14:41] <infinity> elfy: Yeah, that's generally sane debugging.
[14:41] <infinity> elfy: And also lets you offload it on Canonical when Ubuntu is clearly broken too. :P
[14:41] <cyphermox> yeah, looks like I broke ubi-console-setup by merging console-setup.
[14:42] <infinity> cyphermox: \o/
[14:42] <cyphermox> it's now seeing something as preseeded when it probably shouldn't
[14:42] <cyphermox> at least, at a very quick glance
[14:42] <smb> cyphermox, pi tti to figure out the sequence of udev events (again with systemd), someone who knows udev better to figure out a better udev rule. Well there is one ... or was until now that triggers when the block device is added
[14:43] <cyphermox> smb: it might just have to go completely and be all systemd-magical.
[14:44] <smb> cyphermox, maybe for vivid. It might be racing in Trusty too which has no systemd by default.
[14:45] <smb> And not that I can change anything but systemd-magic sounds like bad mojo to me
[14:45] <infinity> smb: Your attempt at not nick hilighting pitti on his vacation is noble, but you realise he's not on IRC, right? :)
[14:45] <smb> infinity, One cannot be careful enough
[14:46] <smb> :-P
[14:46] <cyphermox> smb: after this multipath-tools update it looks like things are much less racy than they were, at least
[14:46] <smb> He probably senses things even while not on irc
[14:46] <cyphermox> hehe
[14:46] <cyphermox> yeah, pitti sense tingling
[14:47] <smb> cyphermox, I should look at those... they have not been there when I last looked
[14:47] <cyphermox> smb: it's one change to not exclusively lock; cherry-picked from upstream, since udev also locks
[14:47] <cyphermox> plus some other crap
[14:48] <smb> cyphermox, ack. I try to pull the latest into my vivid vm and see whether I can get it up more reliably then
[14:50] <elfy> infinity: :)
[15:00] <infinity> Riddell: I'm guessing that mess of KDE packages hitting the queue is expected? :P
[15:00] <infinity> Riddell: Were those for beta, or post-beta?
[15:18] <davmor2> infinity, jibel: Netboot fails, No installable kernel was found in the defined APT sources :(
[15:18] <infinity> davmor2: That sounds rather unlikely.
[15:19] <infinity> davmor2: Which arch?
[15:19] <infinity> davmor2: And which media?  kernel/initrd, mini.iso?
[15:20] <davmor2> infinity: mini.iso, amd64, dvd.
[15:23] <davmor2> infinity, jibel: http://people.canonical.com/~davmor2/image20150324_151921602.jpg
[15:23] <infinity> davmor2: Getting there in my test, hold on. :)
[15:23] <infinity> davmor2: Did you pick a non-standard mirror?
[15:23] <davmor2> gb mirror
[15:24] <davmor2> I love that it gives me the option to Continue without installing a kernel :D cause who needs the kernel right :D
[15:25] <infinity> davmor2: "continue without kernel" and "continue without bootloader" are amazingly handy for port bringups, and for people installing to devices we don't officially support.
[15:25] <infinity> davmor2: But yeah, perhaps a bit dangerous for the average end user.
[15:25] <infinity> davmor2: Then again, it's a screen the average end user isn't ever mean to get to.
[15:27] <davmor2> infinity: indeed
[15:28] <infinity> cjwatson: live-installer has spoiled me, debootstrap from d-i is terribad now.
[15:28] <infinity> cjwatson: Did you ever consider publishing the live squishyfses and using live-installer+http for non-ISO installs too?
[15:38] <ianorlin> hmm do we have documentation on how to get the syslog and other nesecary stuff out when a user does reach the no installable kernel was found in the apt sources screen
[15:40] <infinity> ianorlin: Hit a commandline, anna install openssh-client-udeb, and scp files off.  Not sure if we have a pretty doc anywhere that says that, though.
[15:41] <infinity> ianorlin: And lifes more complicated if network setup fails too.
[15:41] <infinity> life's*
[15:42] <infinity> davmor2: Speaking of, do you have a syslog from that?
[15:43] <infinity> davmor2: I'm expecting to tell you "I can't reproduce that" in a few minutes here, and it might just be that the mirror you used it stuck in the past, but would be nice to see the log.
[15:43] <davmor2> infinity: I can drag it off for you in a moment
[15:48] <infinity> davmor2: So, as expected, I can't reproduce that.  Installation completed fine (amd64/mini.iso) and rebooted.
[15:49] <infinity> davmor2: I did, however, use us.archive, not gb.archive, since you told me that after I started.
[15:55] <davmor2> infinity: http://people.canonical.com/~davmor2/syslog-mini
[15:56] <cjwatson> infinity: Not very hard, although of course it'd be possible.
[15:56] <cjwatson> Mirroring issues etc. though.
[16:00] <infinity> cjwatson: Yeah, I suppose adding root filesystems for every arch to every dists mirror would be less than ideal.
[16:00] <infinity> davmor2: Mar 24 15:15:16 base-installer: W: Failed to fetch http://gb.archive.ubuntu.com/ubuntu/dists/vivid/main/binary-amd64/Packages  Hash Sum mismatch
[16:01] <infinity> davmor2: You just had a mirror hiccup.  A second go should make it work, I'd guess.
[16:01] <davmor2> infinity: I'll give it another go then
[16:02] <infinity> This is a fun bug, though: Mar 24 15:15:07 debootstrap: /var/lib/dpkg/info/keyboard-configuration.postinst: 1: /var/lib/dpkg/info/keyboard-configuration.postinst: udpkg: not found
[16:02] <infinity> cyphermox: ^
[16:02] <infinity> cyphermox: More keyboard fun.
[16:02]  * infinity wonders why it's looking for udpkg in the target...
[16:04] <cjwatson> that code is generated in twisty ways
[16:05] <davmor2> cjwatson: are they timey wimey squirmy wormy ways?
[16:06] <Riddell> infinity: for beta if it's possible/sane
[16:06] <cyphermox> ugh
[16:07] <cyphermox> infinity: err, wait, is that failing or just writing out the error message?
[16:10] <ianorlin> infinity: oh I normally use another method that lets you start a webserver from debian installer itself than wget the files it provides
[16:10] <infinity> Riddell: Your call, really.  Most/all of those are only seeded to your images, so if you want to let things in and respin and retest, that's up to you.
[16:10] <infinity> cyphermox: It's a no-op for Linux, looks like it's a hurd check.
[16:10] <infinity> cyphermox: So, not a big deal.
[16:11] <infinity> cyphermox: Just ugly.
[16:11] <cyphermox> yeah, that's what I was about to say
[16:11] <davmor2> infinity: yeap working now :)
[16:11] <infinity> davmor2: Good deal.
[16:11] <infinity> ianorlin: I prefer the scp method because getting *to* the installed system is often harder than getting *out* of it.
[16:11] <infinity> ianorlin: Especially when debugging on masqueraded VMs, etc.
[16:13] <infinity> Riddell: Just double-check each source with seeded-in-ubuntu before you accept them, please?  So we know for sure that you're only messing with yourself. :P
[16:14] <infinity> cyphermox: Anyhow, sorry, didn't mean to distract you.  The actual keyboard problem should be top priority.
[16:22] <cyphermox> infinity: no worries, I think I know what's wrong, testing the hypothesis now
[16:25] <infinity> cyphermox: \o/
[16:37] <davmor2> infinity, jibel, cyphermox: https://bugs.launchpad.net/ubuntu/+source/indicator-keyboard/+bug/1434091 this is still in the install and it's all cyphermox 's fault ;)
[16:38] <infinity> davmor2: Probably not a high priority for the beta, unless cyphermox's other fixes magically fix it.
[16:39] <davmor2> infinity: indeed :)
[16:41] <cyphermox> doubtful, it would be something quite different I'd expect
[16:59] <flexiondotorg> infinity, I've rebuild Ubuntu MATE. Still no PowerPC iso for Beta 2?
[16:59] <flexiondotorg> stgraber, infinity Suggested you might be able to help with the above? ^^^^
[17:03] <infinity> flexiondotorg: Your powerpc build never happened.
[17:03] <infinity> flexiondotorg: Let's see about resolving that.
[17:09] <cyphermox> ok, got a way to fix the keyboard, just not sure why it comes to that
[17:11] <gaughen> infinity, Hey Adam, I have 3 FFes that need some love. I had poked slangasek but found out he's on vacation. Would you take a look or help me get them some attention? pretty, pretty please?
[17:11] <gaughen> infinity, https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1430760
[17:11] <gaughen> infinity, https://bugs.launchpad.net/ubuntu/+bug/1424029
[17:11] <gaughen> and finally https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1425686
[17:12] <infinity> gaughen: You might note the last commentor on those two lxd ones...
[17:12] <gaughen> darn it! I should have refreshed first!
[17:13] <gaughen> infinity, thank you Adam. I will try to read next time.
[17:13] <infinity> gaughen: Where's the fun in that?  You'd be denied my sarcastic responses.
[17:13] <gaughen> infinity, true and I do like high quality sarcasm
[17:15] <infinity> gaughen: Anyhow, I'll try to look at the docker one sometime, but feel free to poke me harder a bit later.  In the middle of juggling a bunch of things right now.
[17:15] <infinity> And trying to understand why germinate does the things it does which, I think, requires a psychologist, not a programmer.
[17:17] <apw> infinity, it relies on having a very good crystal ball ...
[17:17] <gaughen> infinity, I have a magic 8 ball somewhere I could loan you
[17:43] <doko> gaughen, rbasak, infinity: does docker.io even build in vivid with go 1.3?
[17:43] <infinity> doko: No idea!
[17:44] <rbasak> doko: I don't know but I guess I'll know tomorrow probably
[17:48] <doko> rbasak, good to hear, because a golang update will break several phone builds
[17:48] <flexiondotorg> infinity, I'm all set to rebuild. Is powerpc for Ubuntu MATE all set or shall I hold off?
[17:52] <infinity> flexiondotorg: Hold off.
[17:52] <infinity> flexiondotorg: Other changes are coming anyway, unless you really need to test this one Right Now.
[17:53] <flexiondotorg> infinity, Are those other changes the keyboard thing?
[17:54] <flexiondotorg> infinity, I'll head home and check the back log here a bit later.
[17:54] <flexiondotorg> infinity, I would like to get the OEM testing grub-pc fix today if possible.
[17:54] <flexiondotorg> infinity, Thanks very much for helping. Much appreciated.
[17:55] <infinity> flexiondotorg: The keyboard thing, yes.  And a systemd bug.
[17:56] <flexiondotorg> infinity, Got a LP for the systemd bug? I can test that too when fix it out.
[17:56] <flexiondotorg> *is out
[17:56] <infinity> Erk, who did a langpack export?
[17:56] <infinity> Usually, I'd blame pitti, but he's on VAC...
[17:57] <cjwatson> they're more automated now
[17:57] <cjwatson> so cron probably did it
[18:06] <infinity> cjwatson: Oh.  Really?  No human is signing those anymore?  Fun.
[18:06] <infinity> I guess I'll just reject the lot, I have no urge to try to get them in.
[18:09] <cjwatson> I don't know, guessing
[18:30] <slangasek> infinity: passthrough frontend is rarely used except in update-manager, I think?  were you seeing reports of problems with passthrough or with other frontends?
[18:32] <infinity> slangasek: Passthrough indeed.  I didn't notice that in the log before.
[18:32] <infinity> slangasek: Yeap, passthrough in both duped bugs.
[18:34] <infinity> Riddell: You may have missed a couple of kde things in the langpack noise (which I've cleared out now)
[18:38]  * Riddell looks
[18:39] <infinity> Riddell: libzip was a sync by mdeslaur, but happens to only be on your image.
[18:39] <infinity> Riddell: Given the uploader, I'm assuming security fix.
[18:39] <mdeslaur> yes, only a security fix
[18:46] <infinity> slangasek: Do you know if there's a null client for the Passthrough frontend or something, or if the only way to debug it is from within update-manager?
[18:46] <davmor2> infinity: might be an issue on server installs, the TTY you are in has no text, no prompt and just a flashing cursor and nothing works you have to move to tty 1-6 to do anything like erm login
[20:59] <infinity> Riddell: I'm leaving kubuntu respins up to you or ScottK when all the things you care about are accepted/migrated.
[20:59] <infinity> ScottK: ^
[21:08] <Riddell> thanks infinity
[21:16] <flexiondotorg> infinity, Is the keyboard fix in yet?
[21:17] <infinity> flexiondotorg: It's been uploaded, I'll respin everything except kubuntu once it's migrated and published.
[21:19] <flexiondotorg> infinity, Perfect. Many thanks.
[21:19] <flexiondotorg> infinity, I also saw the PowerPC image too :)
[21:57] <ianorlin> when did debconf break
[21:58] <slangasek> infinity: null client for passthrough> really no idea; cjwatson or mvo might have a better notion
[21:59] <infinity> slangasek: Kay.  Well, I'll sort out some way to test it.
[22:05] <infinity> The passthrough frontend freaking out like this hardly seems like a new issue, Google gives a bajillion hits.
[22:06] <infinity> But it's curious that I seem to have seen several this week.
[22:27] <gaughen> infinity, me again. if you have the time would you look at https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1430760 pretty please?
[22:27] <gaughen> if you are still super slammed. I shall come back tomorrow again.
[22:27] <gaughen> and again
[22:27] <gaughen> and again
[22:28] <infinity> gaughen: Hah.
[22:29] <infinity> gaughen: Commented.
[22:29] <infinity> Typo and all.
[22:36] <gaughen> infinity, thank you!
[22:55] <cjwatson> infinity: debconf hasn't changed in any meaningful way in forever
[22:55] <cjwatson> infinity: there's some stuff in debconf/doc/passthrough.txt that might help
[22:58] <infinity> cjwatson: Oh, it's certainly not a debconf bug, just trying to figure out how to isolate exactly when and where this is happening to blame someone else (likely myself).
[23:12] <infinity> cjwatson: Hah.  Love the "Error Handling" section.
[23:17] <veebers> Hi, is it possible to get the autopilot package into the approved queue?
[23:17] <cjwatson> it was already auto-approved
[23:17] <cjwatson> 22:40 -queuebot:#ubuntu-release- Unapproved: autopilot (vivid-proposed/universe) [1.5.0+15.04.20150226.1-0ubuntu1 => 1.5.0+15.04.20150323-0ubuntu1] (no packageset) (sync)
[23:17] <cjwatson> 22:41 -queuebot:#ubuntu-release- Unapproved: accepted autopilot [sync] (vivid-proposed) [1.5.0+15.04.20150323-0ubuntu1]
[23:19] <veebers> cjwatson: oh, sorry :-P I just saw the 'Unapproved' on both those lines. I didn't take a moment to realise the impact of 'accepted'
[23:19] <veebers> thanks cjwatson for clarifying
[23:19] <cjwatson> that's just referring to the queue in which state changed
[23:43] <infinity> cjwatson: FWIW, "socket -sl" is awesome for this.  Except for the part where I can't get the frontend to crash.  But I can drive it, at least.


[02:09] <dj_segfault> Trying to do software update and autobuilds is timing out.  "W: Failed to fetch http://us.autobuilds.mythbuntu.org/mythbuntu/trunk-0.22/ubuntu/dists/karmic/Release.gpg  Could not connect to us.autobuilds.mythbuntu.org:80 (<IP_ADDRESS>), connection timed out"
[02:10] <silverdulcet> dj_segfault: yeah noticed it was timing out yesterday as well, you could reconfigure the auotbuilds package and try the uk repo, I did that for a while when the us repo was down for a while last time.
[02:11] <dj_segfault> Heh.  Ok.  Just change us to uk in the url?
[02:12] <silverdulcet> dj_segfault: I think you can do a dpkg-reconfigure mythbuntu-autobuilds err, whatever the package is called. Its a deb now.
[02:12] <silverdulcet> then it asks you which repo you want to use, one of the options is uk or us.
[02:13] <silverdulcet> sorry its mythbuntu-repos.deb
[02:13] <dj_segfault> Thanks.  It's mythbuntu-repos for the record.
[02:14] <silverdulcet> you could edit it in the text file, but if you do it through the deb, it keeps things nice and neat for upgrades from them, etc.
[02:15] <dj_segfault> Worked great.  Thanks.
[02:17] <silverdulcet> dj_segfault: np, was kismet, was thinking of doing the same thing if the us repo didn't respond again. ;-p
[02:17] <dj_segfault> I noticed it yesterday too, but I figured it would go away.  Is there someone to notify or will they figure it out?
[02:23] <silverdulcet> dj_segfault: not sure who runs it, last year when it was down it was for quite a while, pretty sure they know about it.
[02:23] <dj_segfault> OK, I guess the squirrels on the treadmill got tired.  I'll leave it as UK for now.  It's fast enough that way
[07:07] <ripperda> hey guys, I'm trying to modify what the power button on my gyration remote does, but I'm having trouble figuring out how it routes through the system. does anyone have experience with that?
[13:32] <Shred00> us.autobuilds.mythbuntu.org appears to be down
[13:33] <Daviey> bah
[13:36] <innatech> Having a problem w/M-buntu Karmic and an HVR-1600 card (CX-18 based) -- S-Video is recording only green bars and garbled audio.
[13:38] <Daviey> Shred00: I've changed the IP address, so you either need to flush your cache or wait for it to expire
[13:38] <Daviey> Shred00: or change to another mirror :)
[13:40] <Shred00> Daviey: :-(  typically one should reduce the TTL to something very small and wait for (old) TTL time to expire before one makes an IP change so that users are not left holding on to an old record for (up to) TTL.
[13:40] <Shred00> i guess i will just have to wait.  i just sucks that apt sits waiting and waiting and waiting until it times out.
[13:41] <Daviey> Shred00: well in this instance it serves no purpose reducing the TTL as the old record doesn't work
[13:42] <Daviey> Shred00: sed -i 's/us.autobuilds/uk.autobuilds/g' /etc/apt/$sourcesfile ; would be a much faster fix for you
[13:42] <Shred00> Daviey: i think you misunderstand.  in advance of changing the ip, you reduce the ttl on the existing RR and then wait for that time before you change the ip.  so if the ttl is a week, you reduce it to 5 minutes, then wait a week before you make the change.
[13:43] <Daviey> Shred00: i think you misunderstand, there isn't a RR
[13:43] <Shred00> before the ip change?
[13:43] <Daviey> There never was
[13:44] <Shred00> how did us.autobuilds.mythbuntu.org ever resolve then?
[13:44] <Daviey> It doesn't need a RR to resolve
[13:44] <Daviey> the TTL is 1hr which is hardly painful anyway.
[13:44] <Shred00> how does us.autobuilds.mythbuntu.org not need an RR?  nobody could ever resolve that name without one.
[13:45] <Shred00> here is the (old) RR right here:
[13:45] <Shred00> us.autobuilds.mythbuntu.org. 166 IN     A       <IP_ADDRESS>
[13:46] <Shred00> here is the new one:
[13:46] <Shred00> us.autobuilds.mythbuntu.org. 3600 IN    A       <IP_ADDRESS>
[13:46] <Daviey> Shred00: by RR i assumed you mean'tRound Robin, but i guess you mean Resouce Record/
[13:46] <Shred00> yes.  RR == Resource Record
[13:46] <Daviey> Shred00: I know what the entries are, *I* just changed them
[13:47] <Shred00> Daviey: but you were denying there was an RR which clearly there had to be so I had to provide evidence to refute your claim that there wasn't one.
[13:47] <Daviey> Shred00: it looks like you had a TTL of 166, so it's hardly a long wait for you anway.
[13:48] <Daviey> Shred00: I'm not sure what you are trying to prove.
[13:48] <Shred00> in any case, the way you minimize the impact of changing an ip is to first reduce the TTL of the existing record.  then wait that long before you make the change
[13:49] <Daviey> Shred00: Ok, next time we have a mirror that doesn't resolve.. i'll ensure that i reduce the TTL to leave people hanging longer.
[13:49] <Shred00> in any case.  it's clear that the problem was just transient.
[13:49] <Shred00> how does reducing the TTL leave people hanging longer?
[13:49] <Daviey> <IP_ADDRESS> is a DEAD mirror, so reducing the TTL for that is foolhardy.
[13:50] <Daviey> So you suggest i reduce the ttl from 1hr (which is pretty short anyway) to 5 mins, wait an hour then make the change?
[13:50] <Daviey> makes no sense.
[13:50] <Shred00> i take this was an "emergency" change then?
[13:51] <Daviey> take it how you please.
[13:51] <Shred00> you didn't say that originally.  you simply said you changed the ip.  i interpreted that as this was a planned change.
[13:55] <Shred00> anyway.  thanx for taking care of it.
[14:01] <DuCkNeT> ouch...
[14:01] <DuCkNeT> i guess he woke up on wrong side of the bed...
[20:08] <tjw> is http://us.autobuilds.mythbuntu.org going to come back eventually?
[20:09] <rhpot1991> tjw: its being worked on, last I saw
[20:10] <tjw> ok, it's been down for a few days, so i was just wondering if i need to reconfigure it to use a different server or something
[20:12] <tjw> i just did 'sudo dpkg-reconfigure mythbuntu-repos' and chose PPA instead of US and that seems to work
[20:12] <tjw> fwiw
[20:12] <tjw> at least I'm hoping they have the same files
[20:36] <slonbg> hi. I'm logged in to my mythbuntu box over ssh. I'm trying to restart the GUI from there with sudo /etc/init.d/gdm stop. Unfortuantely, this command never exits (i.e. does not shut down gdm). Instead, a pupup jumps on the tv with the text "There already appears to be an X server running on dysplay: 0. Should another display number is tried?". How can I restart the GUI from a ssh login?
[20:38] <rhpot1991> slonbg: sudo /etc/init.d/gdm restart
[20:39] <slonbg> rhpot1991: I hit ctrl-c on the gdm stop. with restart, the same popup happen
[20:40] <rhpot1991> is another user logged in or something?
[21:30] <slonbg> rhpot1991: sorry for the delay. No, no other user. Its a standalone machine, connected to the TV. Only remote there. It auto log in to start mythtv. then I login over ssh.
[21:33] <rhpot1991> slonbg: what version of mythbuntu?
[21:34] <slonbg> rhpot1991: 9.04
[21:37] <slonbg> rhpot1991: hmmm. ps aux displays 2 equal gdm lines for /usr/sbin/gdm ...and one for /usr/bin/X .... -auth /avr/lib/gdm/:0.Xauth ...
[21:38] <slonbg> the gdm line are like: /usr/sbin/gdm --config=/etc/gdm/gdm-cdd.conf
[21:39] <slonbg> one has flags Ss, the other only S


[10:30] <digitalmouse> greetings programs!
[12:42] <ompaul> hello world?
[12:44] <ompaul> hi there
[12:47] <rodarvus> @now
[12:47] <Ubugtu> Current time in Etc/UTC: August 07 2006, 10:47:49 - Next meeting: Edubuntu in 2 days


[03:56] <thomi> bschaefer: pong from earlier... although it's a holiday for me :)
[03:56] <bschaefer> yeah I looked it up :)
[03:57] <bschaefer> thomi, no worries, I just got done with class.
[03:57] <bschaefer> I can talk to you tomorrow if you want a day off ;)
[03:57] <thomi> it's cool - I'm about to start hacking on some personal projects
[03:57] <bschaefer> cool!
[03:58] <thomi> So, Ctrl+Space isn't activating ibus in the VM huh?
[03:58] <thomi> that's odd
[03:58] <bschaefer> Im excited to start one up soon
[03:58] <bschaefer> yeah
[03:58] <bschaefer> if you look at the error messge
[03:58]  * bschaefer goes to get it...
[03:58] <thomi> bschaefer: heh, if you're looking for something to do I can suggest several projects for you :P
[03:59] <thomi> bschaefer: I wonder if we can get a test system that's closer to the one that jenkins runs on - maybe we can reproduce some of these intermittently failing tests as well.
[03:59] <bschaefer> thomi, well I might be writing a compiler this summer, or using nux to make a maze solver/generator
[03:59] <thomi> ahh, cool
[03:59] <bschaefer> thomi, AssertionError: After 10 seconds test on SearchBar.im_active failed: True != dbus.Boolean(False, variant_level=1)
[03:59] <bschaefer> so
[03:59] <bschaefer> fails on this line AssertionError: After 10 seconds test on SearchBar.im_active failed: True != dbus.Boolean(False, variant_level=1)
[03:59] <bschaefer> opps
[03:59] <bschaefer> didn't copy haha
[04:00] <bschaefer>   self.assertThat(widget.im_active, Eventually(Equals(True)))
[04:00] <thomi> yeah, so either ibus isn't being activated, or we're not getting the signal
[04:00] <bschaefer> yeah
[04:00] <thomi> I wonder if there's anything we can do to narrow down the cause?
[04:00] <bschaefer> I was thinking maybe a key is getting held down but I couldn't find a key that you could hold downt o cause that
[04:00] <bschaefer> yeah I was wondering that too
[04:00] <thomi> you should be able to see the timings in the test log
[04:01] <bschaefer> so it fails on waiting for ibus to be true
[04:01] <thomi> it logs a line every time it presses and releases a key
[04:01] <bschaefer> hmm
[04:01] <thomi> maybe the delay is too long or something?
[04:01] <bschaefer> well I wanted to add some debuging messages in but I guess you need to merge it to trunk for that
[04:01] <bschaefer> thomi, but it works locally
[04:01] <bschaefer> well
[04:01] <bschaefer> let me try a super long wait
[04:01] <thomi> good idea
[04:02] <bschaefer> ooo thomi hold down ctrl+space
[04:02] <bschaefer> just hold it down and look at the indicator
[04:02] <thomi> I don't get an indicator... hang on
[04:03] <bschaefer> hmm well it toggles on/off
[04:03] <bschaefer> and I got a random crash doing that...
[04:03] <thomi> yeah, I see
[04:03] <bschaefer> very odd that it doesn't fail on the local build though
[04:04] <bschaefer> I tried it in my VM today also
[04:04] <thomi> can you do some subtraction from the trimestamps in the test log and see if the timings are unreasonable?
[04:04] <bschaefer> lowering the ram to like 300 mb
[04:04] <bschaefer> well it hold it for 0.2
[04:04] <bschaefer> which I think is like 200 ms?
[04:04] <thomi> yeah
[04:05] <bschaefer> that seems fast to me
[04:05] <thomi> that doesn't seem unreasonable to me
[04:05] <bschaefer> yeah
[04:05] <bschaefer> I wonder
[04:05] <thomi> heh, I was going to say it's on the slow side :)
[04:05] <bschaefer> if the VM is just slow
[04:05] <bschaefer> though
[04:05] <thomi> that's 1/5 of a second.
[04:05] <bschaefer> yeah haha, but I/O is always slow haha
[04:06] <bschaefer> hmm
[04:06] <bschaefer> Ill see what happen is I just set it to 0.0
[04:06] <bschaefer> or maybe 0.05 haha
[04:07] <bschaefer> thomi, we should have a dx-autopilot-test-jenkins
[04:07] <bschaefer> not being able to debug the VM is not very nice
[04:08] <thomi> bschaefer: if you want to set it up I'm sure we can make it happen
[04:08] <thomi> ... or even set it up on our own jenkins instance.
[04:08] <bschaefer> thomi, Ill have to look into that but that would be awesome
[04:08] <bschaefer> I also need to show you how I set up a VM for unity 3d
[04:08] <bschaefer> thomi, also do you know when the last time the VM was reset?
[04:09] <thomi> I have a jenkins instance for my own projects. I'll talk to people and see how hard it'll be to get running on the PA jenkins machine
[04:09] <bschaefer> like just rebooted
[04:09] <thomi> it gets reset each run
[04:09] <thomi> the dx-autopilot-build-nfsroot job reboots the machine and boots it with a clean image
[04:09] <thomi> ...but that's not the case if we just trigger the dx-autopilot-run job directly
[04:10] <bschaefer> hmm good
[04:10] <bschaefer> I just want to eliminate as many possible problems as possible
[04:11] <bschaefer> thomi, hmm it seems to work at 0.05
[04:11] <bschaefer> ill push it 0.0
[04:12] <thomi> ...assuming the issue is that it's too slow. Worth a shot though
[04:13] <bschaefer> yeah
[04:13] <bschaefer> and 0.0 works fine locally
[04:13] <bschaefer> thomi, there are also some debugging messages in nux I could uncomment....
[04:13] <bschaefer> but I don't want to push just debugging messages to nux trunk
[04:14] <thomi> bschaefer: hmmmm. It'd be nice if there was a copy of the jenkins job we could customise...
[04:14] <bschaefer> yeah I know...all I want is to be able to reproduce this problem
[04:14] <bschaefer> ALL of the test are failing
[04:14] <bschaefer> but I cant get 1 to produce anything jenkins says...
[04:14] <bschaefer> and it is very constant
[04:15] <thomi> hmmm
[04:15] <bschaefer> im just trying to think of anything that could cause that
[04:15] <thomi> if you were feeling brave you could recreate the jenkins config on your local machine
[04:15] <bschaefer> sure, I can set up a VM haha
[04:15] <bschaefer> I actually have a  VM I can toast
[04:15] <thomi> do you have access to the private jenkins instance?
[04:15] <bschaefer> no :(
[04:16] <bschaefer> I could walk you through how to setup a VM sometime soon
[04:16] <bschaefer> though I use windows for my VM
[04:16] <thomi> OK, I can grab the job details and paste them somewhere for you
[04:16] <bschaefer> ok cool
[04:23] <bschaefer> thomi, ugg my schools internet is crap
[04:23] <thomi> :(
[04:24] <bschaefer> just randomly kicked off, anyway did I miss anything?
[04:24] <thomi> nope
[04:24] <bschaefer> cool
[04:24] <thomi> I made fun of you, but that was it
[04:24] <bschaefer> Im happy I missed that then
[04:25] <bschaefer> hmm should I push these ibus test with the time press set to 0.0?
[04:25] <bschaefer> im also wondering if I could use nux to time the inbetween im_active gets active
[04:25] <bschaefer> and deactive
[04:26] <bschaefer> but that might not even be the problem :(, you would think it would work at lease once if it was a timing issue
[04:27] <thomi> bschaefer: I think ideally we'd be able to reproduce the issue before pushing random changes to trunk.
[04:27] <thomi> bschaefer: maybe push 0.1 or 0.05 instead? seems like a more sensible change
[04:28] <bschaefer> thomi, and guess what I did :)
[04:28] <bschaefer> I set the time to 1.0
[04:28] <bschaefer> and it seem to mimic those that problem
[04:28] <thomi> oooh, that's interesting
[04:28] <bschaefer> let me run the Ignore test to see if that works
[04:29] <bschaefer>     self.assertThat(widget.im_active, Eventually(Equals(True)))
[04:29] <bschaefer> AssertionError: After 10 seconds test on SearchBar.im_active failed: True != dbus.Boolean(False, variant_level=1)
[04:29] <bschaefer> :)
[04:29] <bschaefer> both failed
[04:30] <thomi> cool!
[04:30] <bschaefer> ok
[04:30] <thomi> would be interesting to see where the cutoff point is
[04:30] <bschaefer> so, why does 0.2 work for us but not jenkins?
[04:30] <bschaefer> yeah
[04:30] <bschaefer> Ill start going closer to 0.2
[04:30] <thomi> bschaefer: probably because the jenkins instance is slow, so it's closer to 0.4 or somthing
[04:32] <bschaefer> thomi, ooo you were sooo close
[04:32] <bschaefer> it is 0.5
[04:32] <bschaefer> that is start failing fo re
[04:32] <bschaefer> for me*
[04:32] <bschaefer> could be 0.4 on a different machine
[04:33] <bschaefer> thomi, but to be honest that seems like a bug in nux to me
[04:33] <bschaefer> I don't think it should toggle like that...
[04:33] <thomi> bschaefer: probably to do with the tap detection code
[04:33] <bschaefer> yeah, or lack of
[04:33] <bschaefer> im not sure if there is one
[04:33] <thomi> better not say that too loud, the compiz guys will ragequit
[04:33] <bschaefer> haha
[04:33] <thomi> bschaefer: ok, so maybe push a branch that sets it to 0.05 or so
[04:34] <bschaefer> alright, hopefully that helps!
[04:34] <thomi> ping me when you have a MP to review
[04:34] <bschaefer> ok
[04:40] <bschaefer> thomi, https://code.launchpad.net/~brandontschaefer/unity/ap-ibus-shorten-timer/+merge/103407
[04:41] <bschaefer> also what were some other side projects were you doing?
[04:41] <thomi> bschaefer: approved
[04:41] <thomi> bschaefer: right now I'm working on http://launchpad.net/sloecodfe
[04:41] <bschaefer> cool, this should fix 32 failures!!
[04:41] <thomi> *sloecode
[04:42] <bschaefer> thomi, that looks awesome
[04:42] <bschaefer> I actually need to learn something about networking
[04:43] <thomi> bschaefer: we have a todo list that's insanely long :)
[04:43] <thomi> so uhh... "patches welcome" :)
[04:43] <bschaefer> thomi, I might take a look :)
[04:43] <thomi> we hang out in #sloecode
[04:43] <bschaefer> I also might have to wait until I graduate
[04:44] <bschaefer> I do to many things atm haha, being a TA/Tutor takes  a lot of time along with classes and working here
[04:45] <thomi> yeha
[04:45] <thomi> *yeah
[04:46] <bschaefer> Ill stop by that irc room when I get a chance
[04:47] <bschaefer> it is getting a bit late here and I should go eat
[04:47] <bschaefer> thomi, do you know when the next jenkins test should run?
[04:47] <bschaefer> I suck at waiting..
[04:47] <thomi> bschaefer: nope, shouldn't be too long though
[04:48] <thomi> if you're running indicator-jenkins you can get a helpful popup :)
[04:48] <bschaefer> cool, Ill check after dinner
[04:48] <bschaefer> oo
[04:48] <bschaefer> i should install that
[04:49] <bschaefer> well im off to relocate back home, have fun programming :)
[07:12] <tsdgeos> didrocks: ping-y
[07:20] <didrocks> tsdgeos: hey hey
[07:21] <tsdgeos> didrocks: was wondering, might it be that the merger thingy gets confused when a branch name is a subset of another?
[07:21] <tsdgeos> yesterday we merged https://code.launchpad.net/~aacid/unity-2d/load_24bit_pixbuf_icons_2
[07:21] <tsdgeos> and https://code.launchpad.net/~aacid/unity-2d/load_24bit_pixbuf_icons was incorrectly set to merged, Gerry had to put it back to needs review
[07:21] <didrocks> tsdgeos: it's not the merger it's launchpad AFAIK
[07:22] <tsdgeos> ah
[07:22] <didrocks> if it sees commits that are in trunk, it triggered the status to "merged"
[07:24] <tsdgeos> ok :-/
[09:07] <nik90> hi, I am reading a bug report where a user's application and music daemons are not running
[09:07] <nik90> how do I ask him to start them?
[09:07] <nik90> so basically unity-applications-daemon and unity-music-daemon not running as background processes
[09:17] <davidcalle> mhr3, hey
[09:17] <mhr3> davidcalle, hey, awesome you here, wanted to ask you something :)
[09:18] <davidcalle> mhr3, ok, you first :)
[09:18] <mhr3> davidcalle, https://bugs.launchpad.net/bugs/953871
[09:18] <mhr3> is the lens doing something it shouldn't?
[09:18] <mhr3> or is that us?
[09:18] <mhr3> or perhaps it's not doing something it should ;)
[09:20] <davidcalle> mhr3, should be invisible... I don't remember, is there an entry in the .lens for this? Because it's not set, so that may be the issue here.
[09:20] <mhr3> davidcalle, yea, it should have Visible=false
[09:21] <davidcalle> mhr3, ok, fixed. People will have it in a few hours.
[09:21] <mhr3> ultimately we should be clever there, but we ain't so lenses need to provide this info :)
[09:22] <davidcalle> mhr3, I feel like it's the third time I'm fixing this o_o Must be forgetting to push it each time.
[09:22] <mhr3> heh :)
[09:22] <davidcalle> mhr3, is it possible to reload only one filter, without changing the state of the others?
[09:23] <mhr3> it *should*
[09:23] <mhr3> last time i was talking about it with ken, he said that unity doesn't react to the changes
[09:23] <davidcalle> mhr3, I see.
[09:23] <mhr3> and i don't remember anyone fixing it on unity side
[09:24] <mhr3> davidcalle, try removing the filter and then re-add it
[09:24] <davidcalle> mhr3, ok.
[09:24] <mhr3> although that will change the order i guess :/
[09:26] <mhr3> davidcalle, still, i think it should be possible to even remove all the filters and re-add them (if you keep the original references the state wouldn't change iirc)
[09:27] <davidcalle> mhr3, yeah, that's what I was going to do.
[09:43] <nik90> mhr, can you please look at https://bugs.launchpad.net/bugs/987689
[09:43] <nik90> its regarding the application and music lens daemon not running
[09:45] <davidcalle> nik90, if the icons are missing, the lens have probably been uninstalled for some reason. Do you have unity-lens-music installed?
[09:45] <nik90> davidcalle, apparently the user states that both are installed but the daemons are not running for some reason
[09:46] <nik90> davidcalle: he checked the existence of the package using apt-cache policy unity-lens-application
[09:48] <davidcalle> mhr3, what do you think ? ^
[09:49] <nik90> maybe I should ask him to just try unity --reset and see if it solves his problem??
[09:50] <mhr3> starting the lens daemons manually will probably spit some error
[09:51] <mhr3> would be nice to know what kind of
[09:51] <mhr3> nik90, ^^
[09:52] <nik90> mhr, how do you start the daemon manuall?
[09:52] <nik90> manually*
[09:54] <mhr3> /usr/lib/unity-lens-applications/unity-applications-daemon
[09:54] <davidcalle> /usr/lib/unity-lens-music/unity-music-daemon
[09:55] <nik90> mhr, davidcalle..nice synchronisation :)
[09:55] <nik90> I'll inform the user
[09:55] <nik90> thnx
[13:55] <mhall119> more Hello Unity updates: http://mhall119.com/2012/04/hello-unity-episode-3-4/
[14:10]  * mfisch just gave a presentation on Singlet
[14:10] <mfisch> it was well received
[14:10] <mhall119> mfisch: awesome@
[14:10] <mhall119> !
[14:10] <mfisch> mhall119: they wanted to know if singlet was here for the long haul, and I said yes, but of course have no proof
[14:11] <mfisch> mhall119: the best part is that I presented it as "Singlet" and "The Old Way"
[14:13] <mhall119> mfisch: it's here at least as long as I am, which I certainly hope is long haul :)
[14:13] <mhall119> "The Old Way" isn't quite accurate
[14:14] <mfisch> mhall119: true
[14:14] <mfisch> mhall119: the "traditional way"
[14:15] <mhall119> it's also the only way for non-Python lenses and scopes, or anything more complex
[14:44] <seb128> mhr3, hey, do you know if bug #915203 is a lens side issue? a design decision?
[14:44] <seb128> mhr3, i.e having limited number of songs and albums listed
[14:45] <mhr3> seb128, i'm sure would like to put 20 thousand items in the lens, people who implemented the lens didn't
[14:45] <mhr3> ..design would like...
[14:46] <seb128> mhr3, ok, so unity-lens-music is the right component? i.e it's coming from the backend side?
[14:46] <mhr3> yes, its implemented to list only up to 100 items
[14:47] <seb128> mhr3, thanks
[15:15] <hyperair> any lightdm devs around?
[15:15] <hyperair> how does lightdm find out what wallpaper the user is using?
[15:17] <mdeslaur> hyperair: it asks accountsservice IIRC
[15:17] <hyperair> mdeslaur: i see. is it possible to get lightdm to pull the entire wallpaper image through this as well?
[15:18] <hyperair> mdeslaur: if you use a custom wallpaper in your $HOME (i don't see where else you would put it) and chmod o-r $HOME, lightdm refuses to log in.
[15:18] <hyperair> not getting the wallpaper is one thing, but not being able to log in is ridiculous
[15:18] <hyperair> https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/987614
[15:18] <hyperair> we have this bug here
[15:18] <mdeslaur> hyperair: well, that's a bug. It should be able to obtain the wallpaper so it doesn't bypass permissions, but shouldn't fail either
[15:18] <mdeslaur> s/should/shouldn't/
[15:19] <hyperair> it looks like background.vala:138 loads it directly in the unity greeter process
[15:19] <mdeslaur> hyperair: I'm not a lightdm developer, can't help you any further
[15:20] <hyperair> ah, okay thanks anyway
[15:51] <mfisch> mhall119: do you have a simple example of something too complex for singlet?
[15:58] <mhall119> mfisch: the video lens would be one
[15:58] <mfisch> mhall119: whats the reason?
[16:02] <mfisch> mhall119: trying to think of an example to tell people and explain why
[16:04] <mhall119> mfisch: mostly just because Singlet only covers simple cases
[16:04] <mhall119> you can do more complex stuff using Singlet, but you don't get any real benefit from using Singlet at that point
[16:05] <mhall119> it's like Quickly, good for small fast development, but once you reach a certain size it doesn't do you much good anymore
[16:21] <mfisch> got it
[18:19] <bschaefer> lamalex, hey, so thomi and I might have figured out why the ibus test don't work
[18:20] <lamalex> nice!
[18:20] <bschaefer> I pushed some changes last night, but it didn't seem to fix it
[18:20] <bschaefer> it seems when you hold ctrl+space down, ibus toggles on/off
[18:20] <lamalex> ok
[18:21] <lamalex> are we turning it off?
[18:21] <bschaefer> I think it is how fast we detect tabing
[18:21] <bschaefer> for the hud
[18:21] <bschaefer> so events come through faster, so holding it down
[18:21] <bschaefer> will push that event through nux multiple times
[18:23] <bschaefer> I have a different solution but Im not sure how much I like it :(
[18:24] <bschaefer> lamalex, o yeah to reproduce the problem on a local machine. Go into test_ibus.py and under def activate_ibus change the press/release time to 0.5
[18:25] <lamalex> so it's purely timing issue?
[18:26] <lamalex> yarrr
[18:26] <bschaefer> that is what it looks like...
[18:26] <bschaefer> but that is the only way I can reproduce it on a local machine...
[18:27] <bschaefer> I changed the time to 0.05 last night, but it still fails so I think a fix is to iterate from 0.2 to 0.9 and try and press/release ctrl+space
[18:28] <bschaefer> if it activates its the go, else it will drop out and fail on an assert
[18:28] <lamalex> bschaefer, after doing that- now it fails without setting the time for me
[18:28] <bschaefer> hmm really?
[18:29] <bschaefer> what test are you running?
[18:29] <lamalex> autopilot.tests.test_ibus.IBusTestsPinyin.test_simple_input_dash
[18:29] <bschaefer> ok, ill see if I can get the same
[18:33] <bschaefer> lamalex, hmm mine works after setting it back to default
[18:33] <lamalex> odd
[18:33] <bschaefer> yeah...
[18:34] <bschaefer> I have a branch that should find the correct time for presssing ctrl+space...
[18:34] <bschaefer> which should find a correct time, if the timing is the issue
[18:37] <lamalex> odd that this is the only place where key press timing is an issue
[18:37] <lamalex> so you think you understand the root cause of this?
[18:37] <bschaefer> I think it has to do with ctrl+space getting pushing into ibus multiple times in nux
[18:38] <bschaefer> yeah, the problem is Ctrl+Space can change to anything...
[18:39] <bschaefer> also gnome seems to toggle it
[18:39] <bschaefer> but just not as much
[18:40] <bschaefer> well not on pinyin...it really is up to ibus engine then
[18:42] <bschaefer> lamalex, this is one possible fix...https://code.launchpad.net/~brandontschaefer/unity/ibus-ap-test-range-time/+merge/103544
[19:09] <lamalex> bschaefer, this is such a hack :\
[19:10] <bschaefer> lamalex, I know....Ill spend today looking into fixing this in nux
[19:58] <lamalex> thomi, review my branch when you're back! https://code.launchpad.net/~alexlauni/unity/unity.ap-switcher-emu/+merge/103338
[19:59] <gema> hey , wondering if unity is supposed to show the launcher bar and the top bar on all of my screens (3 of them)
[20:00] <gema> and also if the mouse is supposed to get stuck when moving from one to the next (which I find rather annoying)
[20:00] <seb128> gema, yes and yes, and both can be changed in the system settings
[20:00] <gema> seb128: you are a lifesaver
[20:01] <seb128> gema, well the top bar can't, but the display configuration dialog has a combo to select if the launcher should on one screen, which one in that case, or on all screens
[20:01] <seb128> gema, it has a config to turn off the stickyness between screens as well (which is there so you can easily get to a scrollbar against the border)
[20:02] <gema> seb128: already much more usable for me
[20:02] <gema> seb128: thanks
[20:06] <seb128> gema, yw!
[20:10] <bschaefer> thomi, ping
[20:13] <thomi> bschaefer: pong
[20:13] <thomi> lamalex: ok
[20:13] <bschaefer> hey
[20:14] <bschaefer> soo that fix didn't work :I(
[20:14] <bschaefer> :(
[20:14] <lamalex> wah
[20:15] <bschaefer> thomi, ill see if this is a possible fix in nux. The problem is there are multiple keys to activate/deactivate ibus and you can add/subtract from that list
[20:15] <thomi> bschaefer: I saw - odd huh?
[20:15] <bschaefer> yeaah
[20:15] <thomi> lamalex: is there any way to run an identical environment to the one the jenkins instance uses locally?
[20:15] <bschaefer> so it must have a min slow time, ie it is always 0.5 or higher
[20:15] <bschaefer> if it is a timing issue
[20:16] <seb128> thomi, hey
[20:16] <lamalex> thomi, i mean it should be possible to run the nfsbuild root script stuff locally
[20:16] <lamalex> but im not sure how you'd boot the overlayfs image. you'd need a second machine to pxe boot
[20:16] <thomi> lamalex: hmmm
[20:16] <seb128> thomi, lamalex, bschaefer: is there any chance one of you help writing a test for https://code.launchpad.net/~mvo/unity/usc-launcher-fix-982921/+merge/102257
[20:16] <lamalex> i guess really you need a jenkins master and slave set up in your apt
[20:17] <bschaefer> VirtualBox has pxe
[20:17] <seb128> it will not make into the first SRU otherwise
[20:17] <seb128> i.e mvo is maintaining software-center but is not familiar with the unity test framework and he's busy with the precise release (he's looking at i.e upgrade bugs as well)
[20:18] <thomi> lamalex: ok, another idea - do you think we could duplicate the autopilot-run job into another jenkins job that we fire off manualkly? We could point it at a custom unity branch, so we can try things out and run the tests in an identical environment without having to merge with trunk.
[20:18] <lamalex> thomi, yah for sure
[20:18] <lamalex> just make a new job and copy from dx-autopilot run and change the branch ha
[20:18] <thomi> lamalex: we can just go ahead and do that, or do we need to ask someone?
[20:18] <lamalex> thomi, on it
[20:18] <thomi> lamalex: thanks!
[20:19] <thomi> bschaefer: now we can try some wacky fixes and not have to merge with trunk :)
[20:19] <bschaefer> sweet!
[20:19] <thomi> seb128: looking into it...
[20:19] <seb128> thomi, thanks ;-)
[20:19] <bschaefer> I have a bad hack to check if it is a timing issue
[20:20] <bschaefer> thomi, https://code.launchpad.net/~brandontschaefer/unity/ibus-ap-test-range-time/+merge/103544
[20:20] <bschaefer> we should be able to use that to check if/what is the timing problem
[20:21] <thomi> bschaefer: you want to at least sleep before that if statement. It will take a while for unity to update
[20:21] <thomi> you could use wait_for, but then you'd be sleeping 10 seconds each time it didn't work
[20:21] <thomi> also, the more I think about this, the less I think it's a timing issue
[20:21] <bschaefer> hmm yeah,
[20:21] <thomi> The times seem similar to what works for me locally
[20:21] <thomi> and we're seeing 100% failure rate
[20:22] <thomi> so I suspect it's something a bit more basic.
[20:22] <bschaefer> yeah
[20:22] <thomi> bschaefer: a vlue might be to look at what changed when they all started failing?
[20:22] <bschaefer> im hoping...
[20:22] <bschaefer> Ill look through the logs
[20:23] <lamalex> thomi, where do we want this branch
[20:23] <lamalex> lp:~unity-team/unity/ibus-tests
[20:23] <lamalex> sound good?
[20:23] <thomi> yup
[20:23] <thomi> lamalex: we can always tweak the jenkins job config to point it elsewhere, right?
[20:23] <lamalex> yah
[20:24] <lamalex> also going to change the ap run command to just run ibus tests
[20:24] <lamalex> save time
[20:24] <bschaefer> lamalex, awesome, thanks!
[20:24] <lamalex> (will do a test run to make sure we're still seeing same fails this way)
[20:25] <bschaefer> thomi, man, im looking at these test and it has been failing to activate ibus for a while...
[20:25] <thomi> bschaefer: yeah
[20:28] <lamalex> ok should be set to build on every commit
[20:35] <bschaefer> thomi, the first build to not activate ibus correctly
[20:35] <bschaefer> though that is for pinyin only
[20:35] <bschaefer> https://jenkins.qa.ubuntu.com/job/dx-autopilot-run/695/#showFailuresLink
[20:36] <thomi> bschaefer: ok, so what changed in that build? can you see the bzr revno?
[20:36] <thomi> look in the console output for the default configuration
[20:36] <bschaefer> yeah, I started looking for where they ALL started failing
[20:36] <bschaefer> goes to do that
[20:37] <bschaefer> thomi Now on revision 2206.
[20:37]  * bschaefer goes to look at that rev
[20:37] <thomi> uh oh - dx-autopilot-run build just failed.
[20:37] <lamalex> i might have cancelled it
[20:38] <lamalex> i forgot to change the downstream job to the ibus job
[20:38] <lamalex> s/might have//
[20:39] <bschaefer> thomi, http://bazaar.launchpad.net/~unity-team/unity/trunk/changes/2206
[20:40] <bschaefer> im just going to dig until if find anything useful haha
[20:44] <bschaefer> thomi, ugg so a problem, a problem happen between rev 2120 - 2206...since the jenkins test fail for a while
[20:44] <bschaefer> unity rev 2120-2206
[20:45] <thomi> hmmmm
[20:45] <thomi> bschaefer: it could also be a change in the autopilot infrastructure branch that caused it
[20:45] <bschaefer> Ill see if I can find where ALL start failing as that doesn't help at all
[20:45] <thomi> ...or a change oin nux.
[20:45] <bschaefer> yeah
[20:48] <thomi> lamalex: I take it you didn't want to go the extra step and use the Eventually() matcher in your switcher refactor branch?
[20:48] <thomi> I guess it makes sense to do that in a separate branch
[20:49] <lamalex> thomi, where? i thought i did
[20:49] <thomi> oh, ok, there are some, I didn't get to them yet
[20:49] <thomi> I'll add a note in my review
[20:49] <lamalex> there are some places where I couldn't use it- for instance the mode property isn't from introspection
[20:50] <lamalex> i added a card to extend wait_for so that you can use it on properties not added by introspection
[20:51] <bschaefer> thomi, wow even more odd things. What happen to jenkins dx ap builds 723-763?
[20:51] <bschaefer> because after that is were all start to fail
[20:52]  * thomi looks
[20:52] <bschaefer> and it could have happened in unity form 2228-2275
[20:52] <bschaefer> :(
[20:52] <lamalex> erm well, good news- all the tests fail
[20:52] <bschaefer> haha
[20:52] <lamalex> good news in that we get the same results as in the normal AP env with only running ibus tests
[20:52] <thomi> \o/
[20:52] <bschaefer> yeah
[20:53] <lamalex> but you know, still bad news
[20:53] <lamalex> :P
[20:53] <thomi> it'd be funny if they all passed :)
[20:53] <bschaefer> I would .... idk
[20:53] <bschaefer> haha
[20:53] <bschaefer> that would be very inconsistent
[20:53] <thomi> bschaefer: let me finish this review for alex, do the standup, then I'll investigate - will you be around still in 20 minutes?
[20:53] <bschaefer> yup!
[20:53] <bschaefer> Ill dig some more
[20:54] <lamalex> bschaefer, thomi i would just say screw it and have a seperate ibus job
[20:55] <thomi> ibus job?
[20:55] <bschaefer> I ment to dig through nux and the ibus api those logs aren't going to be very helpful :(
[20:56] <lamalex> thomi, as in we'd have two AP test jobs, one for most of the tests one for the ibus tests
[20:57] <lamalex> of course that's moot becuase they failed
[20:57] <lamalex> but had they passed...
[20:57] <bschaefer> or if we can get them to pass :)
[20:59] <thomi> lamalex: https://code.launchpad.net/~alexlauni/unity/unity.ap-switcher-emu/+merge/103338/comments/223103  just a few small tweaks needed :)
[20:59] <thomi> looke awesome otherwise
[20:59] <lamalex> sick
[20:59] <lamalex> will fix now
[21:01] <lamalex> damn i thought i changed that docstring about the tuple
[21:01] <lamalex> wth
[21:03] <gema> can you guys help me add a console based app to the launcher?
[21:10] <gema> nevermind, got it already
[21:10] <NotALamer> hey how does unity figure out what icon and title to use for alt-tab
[21:10] <NotALamer> having trouble getting an application to show up properly
[21:11] <NotALamer> unity is calling it win0 and giving it a generic icon
[21:11] <NotALamer> but xwininfo gives the correct title
[21:14] <thomi> bschaefer: still around?
[21:17] <bschaefer> thomi, yeah
[21:18] <thomi> ...just looking for clues as to the ibus failures...
[21:18] <bschaefer> thomi, was just pulling/compiling that unity-team/ibus-tests branch
[21:18] <bschaefer> yeah, the logs don't seems to help besides a general time line
[21:18] <bschaefer> do you want to push a test in to see if we can find a press/release time that works?
[21:19] <bschaefer> worst case is we can show it is'nt a timing issue
[21:20] <bschaefer> thomi, what if we hold Ctrl, then tab space very fast
[21:21] <bschaefer> instead of having it be "Ctrl+Space"
[21:21] <thomi> bschaefer: worth a shot, although it shouldn't make any difference.
[21:21] <bschaefer> i know :(
[21:21] <thomi> I suspect this is an environmental thing.
[21:21] <bschaefer> ok
[21:22] <bschaefer> dam I wonder if ibus ever gets activated at all
[21:22] <bschaefer> we should start with push some debugging changes I suppose
[21:25] <bschaefer> thomi, can we print out 'ps aux' on that VM?
[21:25] <bschaefer> ps aux | grep ibus
[21:26] <thomi> bschaefer: sure, if you use subprocess and log it in a test
[21:26] <thomi> now that we have a junk branch to push to that's easy :)
[21:26] <thomi> good idea BTW :)
[21:26] <thomi> bschaefer: you want me to set that up?
[21:26] <bschaefer> haha that is true, sure!
[21:26] <thomi> ok, I'm on it
[21:26] <bschaefer> I can look it up, but Ill start trying to figure out how this could happen w/o a timing issue
[21:27] <bschaefer> very odd
[21:27] <bschaefer> and thanks, I like being able to debug things manually haha
[21:30] <bschaefer> thomi, sweet also found a good spot in put a print statement in SearchBar.cpp to see if im active gets set
[21:31] <thomi> cool
[21:31] <bschaefer> did you want to throw it in your branch when you get a chance?
[21:33] <thomi> bschaefer: I just pushed a new revision of that testing branch
[21:34] <thomi> bschaefer: also, your print statemnt won't work, since we're not compiling unity from the branch, only running the autopilot tests
[21:34] <bschaefer> oo
[21:34] <bschaefer> ok
[21:34]  * bschaefer goes to look up some python ibus api
[21:35] <bschaefer> maybe we can add some ibus stuff in the emulator for debugging
[21:35] <thomi> sure
[21:35] <thomi> ok, i just kicked off a new run of the debugging jenkins job
[21:36] <bschaefer> cool
[21:37] <bschaefer> also got that jenkins indicator it is awesome
[21:37] <thomi> thanks :)
[21:38] <bschaefer> o you made it? haha
[21:38] <thomi> yeah,. one of my side projects
[21:39] <thomi> there's several things that I need to fix in it, but it's useful at least
[21:39] <bschaefer> awesome, didn't check who pushed it to launchpad, just pulled it and ran it
[21:39] <bschaefer> yeah!
[21:39] <thomi> bschaefer: there's a PPA as well
[21:40] <bschaefer> O, well it worked from launchpad haha
[21:46] <tiredGeek> On Pangolin, desktop is blank when trying to use vncserver for a remote session.  Can Unity be redirected to another X display?
[21:52] <thomi> hmmm, the ibus test jenkins jobs eems to be hanging
[21:53] <bschaefer> yeah, Im trying to see if we can push the trigger signal through ibus
[21:54] <bschaefer> instead of pressing ctrl+space...
[21:54] <bschaefer> I know how to get the list of shortcuts but need to look more
[21:59] <thomi> bschaefer: hmmm, tht's odd. My debug test fails in a strange way on the server
[21:59]  * bschaefer looking
[22:00] <bschaefer> thomi, so hud doesn't want to show now?
[22:00] <thomi> ok, I made it even simpler
[22:00] <bschaefer> odd
[22:01] <thomi> pushing a version that just does the 'ps' command without trying to show or hide the hud
[22:02] <thomi> re-running it now
[22:02] <bschaefer> alright, also I wonder what would happen if you ran "ibus-setup", isn't it taking a video the whole test?
[22:02] <bschaefer> so we could in a sense have a video of the test, screen shots of ibus-set if anything is wrong with it?
[22:02] <bschaefer> setup*
[22:02] <thomi> sure, except you'd only see the first tab.
[22:03] <bschaefer> yeah
[22:03] <thomi> let's see what this produces first
[22:03] <bschaefer> agree
[22:03] <thomi> brb
[22:04] <bschaefer> ok
[22:04] <mhall119> mhr3: are global search strings still stored in .props.search_string?
[22:04] <mhall119> mhr3: I'm trying to help with http://askubuntu.com/questions/125121/unity-lens-not-included-in-global-search/125186#125186
[22:06] <mhr3> mhall119, i dont think there was such property... ever :)
[22:07] <mhall119> uh...
[22:08] <mhr3> mhall119, not on scopes anyway
[22:09] <mhr3> oh... it is on the LensSearch instance of course
[22:09] <mhall119> yeah
[22:09]  * mhr3 needs time to process stuff this late :P
[22:09] <mhall119> which gets passed to the function listening to search-changed signals, right?
[22:10] <mhr3> yep
[22:14] <mhall119> mhr3: so, Singlet sets search_in_global=False all the time, is it possible that it would still get a search_changed signal on a gloabl search, but with an empty search string?
[22:15] <mhr3> mhall119, are we talking strictly 12.04?
[22:16] <mhall119> I assume, since Singlet only works at all in 12.04
[22:16] <mhr3> cause there was a race in unity4 were that could happen
[22:16] <mhr3> but afaict i fixed it :)
[22:16] <thomi> bschaefer: OK, did you see the results?
[22:17] <bschaefer> looking at it right now
[22:17] <bschaefer> and comparing
[22:17] <thomi> looks good to me
[22:17] <bschaefer> thomi, I have ibus-daemon --xim
[22:17] <bschaefer> and that log has
[22:17] <bschaefer> ibus-daemon -d --xim
[22:17] <bschaefer> I need to look up what that -d does
[22:17] <thomi> -d = daemonise
[22:18] <bschaefer> yeah
[22:18] <bschaefer> hmm
[22:18] <mhr3> mhall119, so, no it shouldn't, and if it does sound alarms :)
[22:19] <mhall119> mhr3: ok, I'll see what responses I get from my current comments, thanks
[22:20] <mhr3> mhall119, i feel bad when i chat with you, you don't make mistakes and you put commas where they should be :P
[22:21] <mhr3> not to mention the capital I :)
[22:22] <mhall119> lol
[22:23] <mhall119> my mother was a paralegal, taught me to write on one of those old smash-the-keys typewriters
[22:23] <mhall119> I still put two spaces after a period, despite all my subsequent English teachers yelling at me for it
[22:24] <bschaefer> thomi, ugg, so im still not sure what could cause this besides that toggling problem.
[22:24] <mhall119> I still make typos though, if you're paying attention
[22:24] <bschaefer> thomi, when I had ibus set to press/release at 0.5 it was failing consistently for me
[22:25] <thomi> bschaefer: hmmm
[22:25] <bschaefer> thomi, hmmm, should we just go ahead and eliminate a timing issue by seeing if the ibus can get active?
[22:26] <thomi> bschaefer: if you look at this: https://jenkins.qa.ubuntu.com/job/dx-autopilot-fix-ibus/3/label=1EBEE0FF-DAC9-11DF-BBDA-64A98C34D485/testReport/autopilot.tests.test_ibus/IBusTestsAnthy/test_simple_input_dash_user_commit_j_/?
[22:26] <thomi> it looks to me like the tap is taking just less than 200mS
[22:26] <thomi> ...which seems reasonable?
[22:26] <mhr3> mhall119, good, otherwise i'd have to assume you installed some clever autocorrect in your irc client :)
[22:26] <bschaefer> thomi, it says 50 ms doesn't it?
[22:26] <bschaefer> for ctrl+space
[22:27] <bschaefer> thomi, also how accurate are those times? it seems like it just prints the var you push into the function
[22:28] <thomi> bschaefer: nope, 201 ms
[22:28] <bschaefer> thomi, wait where are you looking?
[22:28] <bschaefer> Pressing keys 'Ctrl+Space' with delay 0.050000
[22:29] <thomi> oh nuts - I'm being an idiot
[22:29] <thomi> was looking at the Ctrl+a :(
[22:29] <thomi> right, so 23mS for the space key
[22:29] <bschaefer> how are you getting 23ms?
[22:29] <bschaefer> 23mS?
[22:30] <thomi> 22:03:54.965 DEBUG X11:194 - Sending press event for key:
[22:30] <thomi> 22:03:55.017 DEBUG X11:197 - Sending release event for key:
[22:30] <bschaefer> oo
[22:30] <bschaefer> ok yeah duh
[22:30] <thomi> :)
[22:30] <bschaefer> hmm that is very odd
[22:31] <bschaefer> this would be funny. So you can kill the ibus daemon and the ap test starts a new one when you open an engine
[22:32] <bschaefer> so I think a new daemon is getting started each test...nevermind that idea does no where...
[22:32] <davidcalle> jono, poing
[22:32] <jono> hey davidcalle
[22:32] <thomi> hmmmm
[22:33] <jono> davidcalle, nice work on the lens!
[22:33] <jono> davidcalle, I responded to your mail on the list
[22:33] <bschaefer> thomi, so, what could we be missing that we have but jenkins doesn't
[22:33] <bschaefer> could we have*
[22:33] <jono> davidcalle, also, we have #ubuntu-accomplishments if you ever want to hang out there
[22:33] <bschaefer> ugg that is worded very badly...
[22:33] <thomi> bschaefer: possibly an engine, but they should be installed, and the tests should skip if it can't find the engine
[22:33] <bschaefer> or I just can't read right now haha
[22:34] <bschaefer> thomi, yeah, we could print out all engines
[22:34] <davidcalle> jono, thanks. I've seen your answer, when are you going to push your API changes to the PPA ?
[22:34] <jono> davidcalle, the PPA has now been updated
[22:34] <jono> davidcalle, so you should be good to go
[22:34] <davidcalle> Oh, cool
[22:35] <jono> when you have updated the lens I will install the PPA and test too :-)
[22:36] <thomi> bschaefer: hmmm, I'm going to try some things...
[22:36] <bschaefer> thomi, alright...
[22:36] <bschaefer> ill try to think of something...
[22:36] <bschaefer> haha
[22:42]  * thomi kicks off another jenkins run
[22:43] <bschaefer> ugg I have to leave in 20 min
[22:43] <bschaefer> thomi, what are you testing?
[22:43] <thomi> I added a bunch more debugging statements, and made the sleep after we restart the ibus daemon a bit more sensible
[22:44] <bschaefer> cool!
[22:44] <bschaefer> I like the graph, Test Results Trend, all red
[22:44] <thomi> heh
[22:46] <bschaefer> thomi, I don't think it's an engine problem. I removed hangul and those test just reported back as no test taken
[22:46] <bschaefer> so it seem to skip them :(
[22:46] <thomi> good
[22:47] <bschaefer> well yeah
[22:47] <bschaefer> haha
[22:47] <thomi> I'm getting virtualbox set up to PXE boot the remastered CD, so I should have anidentical setupo
[22:47] <thomi> *seup
[22:48]  * thomi waits for CD to download...
[22:48] <bschaefer> yeah, I'll end up doing that when I get back form this seminar I have to go too...
[22:48] <bschaefer> to*
[22:52] <bschaefer> thomi, ugg well I have to go for a bit. Ill be back in a couple hours, good luck!
[22:54] <thomi> cheers