[03:51] <robru> thomi, hey, you want to merge my memevent branch asap?
[03:51] <thomi> robru: yes please!
[03:52] <robru> thomi, k, the thing is, my jasmine-unit test branch is a prerequisit, and it's unreviewed.
[03:52] <thomi> link me?
[03:52] <robru> thomi, not sure if I should merge that, or resubmit without it
[03:52] <thomi> merge it
[03:52] <robru> thomi, https://code.launchpad.net/~robru/uci-engine/jasmine-unit-testing/+merge/228229
[03:53] <robru> thomi, ok, will merge. wouldn't mind a 'lgtm' ack on the mp though
[03:53] <thomi> ok, just reviewing this one ^
[03:55] <thomi> robru: first one approved
[03:56] <thomi> robru: one thing, shouldn't it be 'KB' for kilobyte?
[03:56] <robru> thomi, ok, it's merged.
[03:56] <thomi> 'b' == bit, 'B' == 'byte'
[03:56] <robru> thomi, uhhh...
[03:56] <thomi> and is it a KB or a KiB?
[03:56] <robru> veebers, is it kilobits or kilobytes? ^^
[03:57] <thomi> ... or kibibytes?
[03:57] <veebers> robru, thomi ugh, let me re-check now
[04:03] <veebers> comparing the results of smem-tabs gives me '618980' without units and '604.6M' with  units
[04:04] <veebers> also,  '316' and  '316.0K'
[04:04] <thomi> OK, so the correct unit is 'kiB'
[04:04] <thomi> or KB, if you want to ignore SI
[04:05] <thomi> but certainly not 'kb' or 'K'
[04:06] <thomi> and not 'kB', which is 1000 bytes, not 1024
[04:20] <robru> thomi, veebers sorry I have company over one sec
[04:21] <robru> thomi, ok, it's pushed to trunk. didn't get time to look at chris g's thing today because I was so swamped with everything.
[04:22] <robru> thomi, you should probably do a local deployment before going live with IS, that jasmine branch had a lot of big changes.
[04:25] <thomi> robru: OK, I'll try and get around to doing a deployment. even bvetter would be if veebers got juju setup
[04:26] <robru> veebers, make sure you run `mkdir -p /usr/local/bin`. juju completely falls over without any sort of useful error messages if that directory happens to be missing on your system. stymied me for an entire month.
[04:26] <veebers> o_0 nice
[04:27] <robru> veebers, yeah there's some deep dark corner of juju where it tries to make a symlink there, but does so without checking if the directory exists first. and if the direcotry doesn't exist, the symlink fails, and then the whole thing falls over
[04:27] <robru> but I really gotta go, i have company over.
[13:18] <barry> nuclearbob: \o/  * Remove python2 compatibility code from autopilot.
[13:53] <nuclearbob> barry: yeah, I've been working on that one since Malta


[12:33] <BenC> mjg59: I've been git-rebase'ing on linux-2.6 throughout gutsy
[12:33] <BenC> will continue to do so until 2.6.22 is released
[12:33] <mjg59> BenC: It appears to make pulling immensely painful
[12:34] <BenC> git-pull -f? :)
[12:34] <crimsun> I basically have to erase my cloned copy and reclone.
[12:34] <mjg59> It also makes the history a mess
[12:35] <mjg59> Shouldn't you juts be pulling upstream?
[12:36] <BenC> I have patches being merged upstream, rebasing is easier
[12:37] <BenC> plus it'll make it easier when we move to gutsy+1, I can fixup each patch individually and not have to have a huge merge delta separate from the actual commits
[12:37] <BenC> how does it make the history a mess
[12:38] <mjg59> Everything appears to be committed on the day you rebase, as far as I can tell
[12:38] <BenC> there's got to be an easy way to keep synced with a rebased tree, most of the trees that linus pulls from get rebased all the time
[12:38] <mjg59> No, Linus tells people not to rebase
[12:40] <mjg59> (for the most part)
[12:41] <BenC> Well rebasing is making the tree a lot easier to maintain, and makes me not dread gutsy+1, so we might have to figure out how to make it easier for you guys to pull when it happens :)
[12:41] <mjg59> The history is regenerated. As far as I can tell, that effectively makes pulling impossible
[12:42] <BenC> but there has to be a way to do it
[12:42] <mjg59> If I was following Linus's tree, it'd probably be ok
[12:42] <BenC> kyle, pkl and rtg are doing it
[12:42] <BenC> if you have gutsy git you have Linus's tree :)
[12:43] <mjg59> But right now, I pull and get a huge number of conflicts under debian/
[12:43] <mjg59> Because they've effectively been deleted and readded
[12:43] <jmg> how come 8316 got assigned to jeff and 8244 got assigned to albert lee?
[12:45] <jmg> and what do you make of this? http://bugzilla.kernel.org/show_bug.cgi?id=8244#c15
[12:45] <jmg> 1. Ubuntu Linux issues an incorrect INQUIRY command to the drive. (Other distros seem to have the INQUIRY correct.)
[12:58] <BenC> mjg59: you could try using git-fetch origin; git-reset --hard origin
[12:58] <BenC> not sure if that will work
[05:34] <calc2> anyone know how i could go about building just a subdir of the kernel, eg sound/pci/hda ?
[05:35] <calc2> i'm trying to write support for the Realtek 268 audio codec
[05:48] <calc2> bbl, laptop is dying
[05:48] <calc2> grr battery doesn't last much with wireless on
[09:37] <abogani> Hi all, Please help me! Reply to my last email in the kernel ml!
[09:41] <crimsun> well, there seem to be all sorts of things missing.  Was the merge sane and actually correct?  No missing structs?
[09:41] <crimsun> (I guess those were dumb questions, since the merge wasn't sane...)
[09:42] <crimsun> hmm, and upstream already merged alc268 support.
[09:42] <crimsun> Guess Chris will get his wish without blinking.
[09:48] <abogani> crimsun: No missing struct (to my eyes) :-(
[10:03] <abogani> crimsun: Uhhhi without CONFIG_SMP -rt kernel compile! :-?
[10:03] <abogani> Perphaps realtime-patch add some ifdef/ifndef ?
[10:33] <kraut> moin
[12:16] <jmg>  OH NO! upgrading to gutsy hardswitched my wireless off :'((((
[12:17] <jmg> Radio Frequency Kill Switch is On:
[12:17] <jmg> Kill switch must be turned off for wireless networking to work.
[12:24] <jmg> augh, and i deleted windows
[03:00] <abogani> BenC: Do you a minute for me?
[04:00] <newz2000> is it remotely interesting that I get 'bug soft lockup detected on cpu#0' on a dapper server running in vmware, repeatable whenever I try to do mkfs.ext3?
[04:01] <newz2000> I know what's causing the problem (the disk was partitioned on another computer and the vmware bios detected it with different settings.
[04:49] <lamont> BenC: you about?
[04:50] <BenC> lamont: yeah
[04:50] <lamont> the linux-headers-$mumble-{itanium,mckinley} packages are missing a symlink...
[04:50] <BenC> yeah, I meant to fix it on the last upload
[04:51] <lamont> arch/ia64/module.lds
[04:51] <BenC> Yeah, silly ia64 :)
[04:51] <lamont> and then I have a patch to linux-ubuntu-modules
[04:51] <BenC> ok
[04:52] <lamont> and I wonder if hppa also needs module.lds...
[04:52] <BenC> the fix should do it for any that have *.lds
[04:52] <lamont> right
[04:54] <lamont> how would you like me to handle the linux-ubuntu-modules?
[04:56] <lamont> 21 line unidiff that (unfortunately) adds WLAN_IA64 (a constant.. suckage) and setting vars to that
[04:57] <BenC> you can either send me a diff via kernel-team@ or I can get you on kernel.ubuntu.com (zinc.ubuntu.com) and you can do some clones I can pull from
[04:57] <lamont> hrm... the first is easier for me, the second is probably the right direction longer term, no?
[04:58] <BenC> yeah, patch now, and account request to follow sounds good
[04:58] <BenC> you can send me a login name and ssh key for that
[04:59] <lamont><EMAIL_ADDRESS>[04:59] <BenC> yeah, sounds good
[05:00] <lamont> you prefer rsa or dsa keys?
[05:01] <BenC> Doesn't matter to me personally and elmo never gave a preference
[05:02] <lamont> sent
[05:03] <BenC> thanks, will forward that along to admin and they'll email you when it's setup
[05:05] <lamont> thanks
[05:06] <lamont> once the kernel fix is there, then linux-ubuntu-modules (patched) will build, and debian-installer stands a chance of building.
[05:31] <abogani> BenC: Do you a have a minute for me? :-)
[06:06] <abogani> When will be released 2.6.22-7 ?
[08:03] <mjg59> BenC: Any chance we can test http://www.codon.org.uk/~mjg59/tmp/ahci.quirk ?
[08:04] <BenC> mjg59: weren't all the piix/ahci quirks removed awhile back?
[08:05] <BenC> mjg59: do you want to just send me a login and ssh key for kernel.ubuntu.com so you can do some gitness? :)
[08:05] <mjg59> BenC: I don't think we ever had anything that tried to shift piix over to ahci
[08:06] <BenC> mjg59: what's the reason for the patch? Does it override BIOS legacy/native mode or is this working around a bug in the BIOS for AHCI mode to work properly?
[08:07] <mjg59> Right now, if the BIOS has set the device up for both AHCI and legacy mode, we'll drive it as a legacy device
[08:07] <mjg59> It'd be preferable if we could use it in AHCI mode
[08:07] <mjg59> Especially with the link level power saving stuff appearing
[08:13] <BenC> Ok, sounds reasonable...how much testing has it had so far?
[08:13] <mjg59> Well, that's why I'd like to push it slightly wider :)
[08:13] <mjg59> On most machines it'll be a noop
[08:14] <mjg59> On my Apple, it works
[08:14] <mjg59> There's the /potential/ for BIOSes to program random shite into the BAR
[08:14] <mjg59> But it's basically impossible to know unless people run it
[08:38] <geser> I'm upgrading to gutsy and I'm missing the prism54 drivers from the 2.6.22 kernel. Does somebody know where I find them?
[08:39] <mjg59> geser: linux-ubuntu-modules ?
[08:39] <mjg59> Oh, wait, no - that should be mainline
[08:44] <geser> in the config for 2.6.20-16 it's CONFIG_P54_* but this option isn't listed in 2.6.22 anymore
[08:45] <geser> btw got the lowlatency kernels got dropped in gutsy?
[09:57] <crimsun> geser: yes, due to tickless.
[09:58] <geser> ah
[11:19] <tsmithe> hi
[11:19] <tsmithe> i was wondering about getting alsa-firmware into linux-restricted-modules for gutsy
[11:20] <crimsun> git changeset.
[11:20] <crimsun> cough.
[11:20] <tsmithe> yes yes
[11:20] <tsmithe> i'm not totally sure how to accomplish that, ok!
[11:20] <tsmithe> :P
[11:20] <tsmithe> also, having one of these git changesets isn't going to help unless i can get it included
[11:21] <tsmithe> so i need to know about the process for that too ;)
[11:32] <crimsun> well, clone l-r-m first
[11:33] <crimsun> then go through the addition locally, then generate a changeset
[11:33] <crimsun> or ask for access using the procedure outlined in the wiki
[11:53] <tsmithe> is the process for making the addition outlined in the tree?
[11:57] <crimsun> no, you should probably read git-core documentation for that
[11:57] <crimsun> e.g., www.kernel.org/git/
[11:58] <tsmithe> righty
[11:59] <tsmithe> well i'm off to sleep now :)
[12:12] <astronouth7303> How would I obtain and compile the coretemp module for my currently installed kernel?


[08:30]  * ppisati -> reboot
[08:54] <vaneet> Hi everyone.
[08:55] <vaneet> I know a bit of linux and i am not an expert.
[08:55] <vaneet> I have installed 11.10 ubuntu from CD
[08:55] <vaneet> many times during the day, it crashes
[08:55] <vaneet> i read yesterday that desktop GUI issues are normally kernel issues.
[08:55] <vaneet> can someone help please.
[08:55] <vaneet> thank you in advance
[09:03] <vaneet> anyone there
[09:22] <vaneet> hi
[09:28] <didrocks> hey apw! I normally get a kernel panic every 2 days (my disk is really slow and I'm under the impression that I trigger it when I do a lot of ios). This morning, I got 3 of them :( what should I provide to help your team debugging?
[09:56] <apw> didrocks, do you get a stack trace from the crash, thats the most useful part
[09:56] <didrocks> apw: never got a crash in /var/crash/ related to the kernel from what I can see
[09:57] <apw> didrocks, so whats the symptoms when it 'crashes'
[09:58] <didrocks> apw: the disk is spinning a lot due to a lot of io, then screen freezes and I see both caps lock and scroll lock flashing which is what tells there is a kernel panic, isn't it?
[09:59] <apw> didrocks, yes usually flashing those is its last ditch attempt to tell you ... from their its worth doing the sysrq sync  as if syslog got the crash it may not hit the disk until you sync
[10:00] <didrocks> apw: ok, will do the sysrq sync at my next (hopefully not too soon though ;)) crash
[10:00] <didrocks> apw: will keep you posted
[10:00] <apw> didrocks, which kernel is this running, assuming precise latest?  so do get a bug filed so we can track which versions it definatly occurs in
[10:01] <apw> didrocks, i don't think i've seen any hard crashers this cycle on any of my kit thankfully, they are very hard to locate
[10:01] <didrocks> apw: yeah, I got that for 2/3 weeks already, always updated to latest (and updated to latest again this morning)
[10:01] <didrocks> apw: yeah, I really think I trigger it a lot as my HD is near EOL
[10:01] <didrocks> so all my laptop is very slow due to this, so easier for me to trigger weird cases
[10:02] <apw> didrocks, i asume its not old enough to have a serial port
[10:02] <apw> why oh why did they take those off
[10:03] <didrocks> apw: no, I would have played with minicom otherwise ;)
[10:04] <apw> didrocks, sometimes a netconsole will get the crash, sometimes
[10:04] <didrocks> interesting, not used to do that though ;) for most of my stack, it's either on a terminal or a tty if it's the window manager. Quite easier ;)
[10:09] <apw> didrocks, fingers crossed the sync will get it
[10:09] <didrocks> apw: I hope so as well. Will keep you in touch, thanks!
[10:10] <apw> and let us know the bug number so we can get it to jo
[10:10] <apw> joe
[10:18]  * ppisati -> back in a bit
[11:08]  * ppisati -> lunch
[11:14] <cking> ditto
[11:33] <ppisati> *burp*
[11:35] <cking> satisfying lunch then ppisati?
[11:42] <ppisati> well, good enough, thanks for asking :)
[12:02] <smb> ppisati, Wanna mint? :)
[12:13] <ppisati> smb: the meaning of life? :)
[12:13] <smb`> ppisati, yep
[12:13] <smb`> :)
[12:37] <apw> b smb
[12:37] <smb> b happy
[13:08] <Teduardo> Anyone have any clue when 12.04 will be happily thrust upon us?
[13:10] <smb> When it is released...? ;) https://wiki.ubuntu.com/
[14:01] <Kano> hi, please add http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=c9651e70ad0aa499814817cbf3cc1d0b806ed3a1
[14:01] <Kano> if not already done
[14:07] <ppisati> apw: https://wiki.ubuntu.com/KernelTeam/Specs/PreciseKernelConfigReviewBeta2omap4 is it periodically autogenerated or you intervene manually?
[14:08] <apw> ppisati, totally manual, need it updating ?
[14:09] <ppisati> apw: not yet
[14:10] <apw> Kano, that is already applied and uploaded, iirc we were in the loop in getting that fix identified
[14:11] <Kano> fine
[14:11] <Kano> i bisected it again ;)
[14:11] <Kano> then i saw that there was already a fix
[14:42]  * ogasawara back in 20
[14:45] <ppisati> apw: when there's a dash it means it's not available there, right?
[15:00] <apw> ppisati, yes right
[15:19] <tgardner> cking, do you have a regression test for bug #885744 ? It needs Oneiric verification.
[15:19] <ubot2> Launchpad bug 885744 in ecryptfs "pathconf() does not reflect reality" [High,In progress] https://launchpad.net/bugs/885744
[15:19] <ogasawara> tgardner: I'm gonna rebase q to 3.4-rc1, just wanted to make sure you're not already doing so
[15:19] <cking> tgardner, yep, I'm in the process of verifying these
[15:19] <tgardner> ogasawara, nope, still grinding through my email backlog. thats what I get for taking the weekend off.
[15:20] <tgardner> cking, thanks
[15:21] <tgardner> cking, which reminds me, I should compare 2.6.32.y against our ecryptfs patches and send the deltas to stable
[15:33] <jwi> apw: otoh, the aspm fix hasn't been applied to oneiric-proposed yet...
[15:43]  * ppisati kicks another build and disappears for a bit in the mean tim
[15:43] <ppisati> e
[15:43] <tgardner> jwi, just emailed it for review at<EMAIL_ADDRESS>[15:48] <apw> tgardner, do we not need a second fix from cking on that one ^ ?
[15:48] <tgardner> apw, nah, taht was just an override thingy. it wouldn't hurt, but its also not related
[15:49] <cking> yep
[15:49]  * apw looks confused
[15:49]  * apw will let you duke it out on the mail thread
[15:50] <tgardner> apw, you're takling about Oneiric "ASPM: Fix pcie devices with non-pcie children", right ?
[15:50] <apw> tgardner, indeed
[15:50]  * apw spits feathers at the launcher, get off my damn screen i am using it
[15:51] <tgardner> apw, and I assume to 2nd patch to which refer is "UBUNTU: SAUCE: PCI: Allow pcie_aspm=force to work even when FADT indicates it is unsupported"
[15:52] <apw> cking, is that the one i mean, i know there was a followup for it, which was related to regressions induced by the first patch
[15:58] <apw> bah it wants to remove all my 32 bit support again ... not a good time to update
[16:07] <apw> ppisati, did we resolved the issues that pushed us back for beta2 on arm?
[16:36] <tgardner> sforshee, have you noticed suspend/resume issues on your MB Air ?
[16:36] <sforshee> tgardner, I filed a bug about some touchpad problems after S3, but that's the only one I've seen recently
[16:37] <tgardner> sforshee, yeah, I'm seeing mouse lockage
[16:37] <tgardner> sforshee, I didn't notice it until recently 'cause I'd been using an external mouse
[16:37] <sforshee> it just showed up recently
[16:38] <sforshee> tgardner, bug 968845
[16:38] <ubot2> Launchpad bug 968845 in xserver-xorg-input-synaptics "bcm5974 touchpad doesn't work after S3" [Undecided,Confirmed] https://launchpad.net/bugs/968845
[16:38] <sforshee> if you suspend from the menu things are okay
[16:38] <tgardner> sforshee, do you have time to bisect for it? is it a kernel issue ?
[16:38] <sforshee> tgardner, I'm pretty sure it's not a kernel issue
[16:38] <tgardner> ah, then not a kernel problem
[16:39] <sforshee> tgardner, I subscribed cnd to the bug, hopefully he'll have some input
[16:40] <cnd> sforshee, tgardner: no input :(
[16:40] <cnd> I don't know what might have changed
[16:40] <cnd> but there has been some work done to the bcm5974 and suspend stuff
[16:41] <cnd> there might be upstream patches in 3.3 or 3.4 that fix it too
[16:41] <sforshee> cnd, it seems like the touchpad still works fine, just that userland isn't doing anything with it
[16:41] <sforshee> i'll check upstream for patches though
[16:42] <cnd> sforshee, are you saying that evtest still works, for example, but no events are coming through X?
[16:43] <sforshee> cnd, input events shows reasonable-looking events, and if I restart lightdm it starts working fine on the desktop
[16:45] <cnd> sforshee, try using xinput test-xi2 to see if you get events from X
[16:46] <sforshee> cnd, yes, I get events
[16:46] <cnd> sforshee, so you get events, but the cursor doesn't move?
[16:46] <sforshee> exactly
[16:46] <cnd> sforshee, what kinds of events are you getting when you use one finger?
[16:46] <cnd> touch or motion?
[16:46] <sforshee> oh, sometimes I get right clicks too
[16:47] <sforshee> cnd, I see RawTouch* events
[16:47] <cnd> sforshee, ok, we don't care about raw events for now
[16:47] <sforshee> that's all I'm seeing
[16:48] <cnd> sforshee, what non-raw events do you see if you put two touches down?
[16:50] <sforshee> cnd, none, just RawTouch stuff
[16:51] <cnd> sforshee, and three touches?
[16:51] <ppisati> apw: nope, since my panda's video out is still broken, waiting for the new one
[16:51] <cnd> also, please pastebin the output of "xinput list-props bcm5974"
[16:51] <ppisati> apw: i think it'll have to wait until after first SRU
[16:52] <ppisati> apw: since thursday is KF
[16:52] <sforshee> cnd, the same
[16:52] <cnd> hmm
[16:53] <cnd> sforshee, check for any errors in your Xorg.log
[16:54] <sforshee> cnd, the only thing I find are some "unable to find touch point 0" messages
[16:54] <cnd> hmm... that could be related
[16:55] <cnd> sforshee, I seem to recall someone saying that on lid closure the trackpad sometimes emits touch events
[16:55] <apw> ppisati, kernel freeze means we move to SRU mode, limiting updates without appropriate acking, its not impossible to get things in, and easier probabally than after release
[16:55] <apw> ppisati, where is your replacement coming from?
[16:55] <cnd> I don't know if it's a capacitive effect or merely your fingers are close to it when closing the lid
[16:56] <cnd> I wonder if some evdev events are getting lost at suspend/resume time
[16:56] <cnd> so a touch is stuck in the "open" state
[16:56] <cnd> sforshee, it might be worthwhile to do a suspend/resume while recording events using evtest
[16:56] <sforshee> cnd, here's something strange
[16:56] <apw> we probabally reset the thing having powered it off for suspend
[16:56] <cnd> and then seeing if there are any anomalies
[16:56] <ppisati> apw: austria, but "upstream" didn't deliver any boards to them yet, it seems there's a shortage
[16:57] <sforshee> I'm noticing that right now my one-finger touches are behaving like two-finger touches; i.e. they are causing scrolling
[16:57] <cnd> sforshee, ahh yes!
[16:57] <cnd> that's exactly what I was thinking might be happening
[16:57] <apw> ppisati, and we don't have any you can test on anywhere we can either get you access to 'em or send one to you?
[16:57] <cnd> sforshee, a touch is stuck in a state where X thinks it is active
[16:57] <ppisati> apw: pgraner told me he was sending me a board this week
[16:58] <cnd> sforshee, how reproducible is it?
[16:58] <ppisati> apw: actuallyt i could try another rebase tomorrow, and shell it to someone on #arm
[16:58] <sforshee> cnd, it happens 100% of the time if I suspend using the lid
[16:58] <ppisati> apw: for testing
[16:58] <apw> ppisati, well thats something, but we should hastle as the timeing is very poor
[16:58] <apw> ppisati, yes use them and abuse them
[16:58] <cnd> sforshee, ok, then do the evtest thing during a suspend/resume
[16:59] <cnd> let's see if we catch any bad events
[16:59] <sforshee> cnd, ack
[16:59] <apw> cnd, i wonder if it sees its own lid :)
[16:59] <cnd> apw, could be :)
[16:59] <ppisati> apw: just to clarify, the TI stuff is up to date (no more pulling from them) we are slacking behind wrt to master
[16:59] <pgraner> ppisati, I sent it to millbank and msm will be sending it down to you
[16:59] <ppisati> pgraner: k, thanks
[17:01] <apw> ppisati, ok its arrived in london and i'll be winging its way tommorrow
[17:01] <sforshee> cnd, is it important that there be a suspend/resume, or just a lid close/open? Because the device is being grabbed when I'm on the desktop, so evtest can't get the events.
[17:01] <ppisati> apw: cool
[17:01] <cnd> sforshee, switch to a VT
[17:01] <cnd> then run evtest
[17:02] <cnd> oh, but then it doesn't suspend
[17:02] <cnd> I see
[17:02] <sforshee> yep :)
[17:02] <cnd> sforshee, so you can use an Xorg.conf rule to tell X not to grab the device
[17:02] <apw> cnd, we need a bpf for the events ...
[17:02] <sforshee> I can do sleep 2; pm-suspend on the VT
[17:02] <cnd> apw, bpf?
[17:03] <apw> berkely packet filter, its whats uses to pick out ehternet frames, and i tink now usb and bt frames
[17:03] <apw> and they were using it for something else mad the other day, now what was that
[17:03] <apw> seccomp maybe it was
[17:03] <sforshee> syscall filtering
[17:03] <sforshee> yep
[17:03] <apw> so it must be the right thing for event monitoring :)
[17:03] <cnd> heh
[17:04] <cnd> sforshee, there's a better way to do this
[17:04] <cnd> but the faster/hackish way is:
[17:05] <cnd> add 'Option "GrabEventDevice" "false"' to /usr/share/X11/xorg.conf.d/50-synaptics.conf
[17:05] <cnd> inside the touchpad catchall block
[17:05] <cnd> I don't think you'll see any issues when you have the option set
[17:05] <cnd> I think it's there for a couple of very specific circumstances
[17:06] <cnd> sforshee, once you've added it, you need to log out and back in
[17:06] <cnd> then you should be able to evtest while in X
[17:06] <apw> stopping people reading your keyboard while you are typing perhaps
[17:06] <cnd> apw, no, that input class section is only for trackpads
[17:07] <cnd> at one point I knew why we grabbed devices by default
[17:07] <cnd> it papers over missing functionality needed in the X synaptics driver
[17:07] <apw> i am glad to hear your brain has flushed that information
[17:07] <apw> mine does it all the time
[17:07] <cnd> heh
[17:08] <sforshee> cnd, that seems to be working
[17:08] <cnd> cool
[17:10] <sforshee> cnd, http://pastebin.ubuntu.com/911740/
[17:13] <cnd> sforshee, did all this occur just by closing the lid?
[17:13] <apw> oh joy firefox, chromium, and libreoffice updates ...
[17:14] <sforshee> cnd, i did wiggle my finger on the touchpad after resume
[17:14] <cnd> sforshee, oh...
[17:14] <cnd> sforshee, can you get a clean recording without any intentional touchpad interaction?
[17:14] <sforshee> I can redo it without the wiggling
[17:14] <cnd> thanks
[17:14] <apw> cnd, though its reporting a 4 finger touch right?  and i assume he only did one
[17:15] <apw> or he used his forhead
[17:15] <sforshee> i always use my forhead, is that unusual?
[17:15] <cnd> heh
[17:15] <cnd> apw, good point
[17:15] <cnd> sforshee, did you only use one finger?
[17:15] <apw> but you do want a clean 'un
[17:15] <sforshee> cnd, yep, one finger
[17:16] <cnd> hmm... then my guess is the driver is screwed up too :)
[17:17] <cnd> sforshee, btw, you can probably reset the state back to a good starting point by reloading the bcm5974 driver
[17:17]  * tgardner relocates
[17:18] <sforshee> cnd, non-wiggling evtest output: http://pastebin.ubuntu.com/911751/
[17:18] <cnd> sforshee, really?
[17:18] <cnd> there's a ton of stuff going on :)
[17:18] <cnd> but it's masked by bad state too
[17:19] <apw> Event: time<PHONE_NUMBER>.147384, type 3 (EV_ABS), code 50 (ABS_MT_WIDTH_MAJOR), value 7630
[17:19] <apw> Event: time<PHONE_NUMBER>.147386, type 3 (EV_ABS), code 51 (ABS_MT_WIDTH_MINOR), value 6492
[17:19] <sforshee> cnd, reloading bcm5974 did get pointer motion back, and compiz also crashed :)
[17:19] <cnd> sforshee, can you do the same after reloading the driver?
[17:19] <apw> waht the resolution of this thing ?
[17:19] <cnd> fun...
[17:19] <apw> thats a pretty big finger in most coordinate systems
[17:19] <cnd> apw, look at the top of the printout
[17:19] <cnd> it gives the axis max and min for each code
[17:19] <cnd> it has a pretty high resolution :)
[17:20] <apw> so those are outside the surface area then no ?
[17:20] <sforshee> cnd, you want the evtest output again after reloading the driver?
[17:20] <cnd> looks like it
[17:20] <cnd> sforshee, yeah
[17:20] <apw> as its saying 1280x800, and then saying you have a 7k wide finder
[17:20] <apw> finger
[17:20] <apw>       Max     2048
[17:20] <apw> so that number can't be >2k ... ooops
[17:21] <cnd> apw, or the driver writer had never seen a value higher than that
[17:21] <cnd> the X and Y max and min for the magic trackpad are merely the highest and lowest values I could get
[17:21] <cnd> we don't have specs for apple devices :(
[17:21] <apw> ahh ok
[17:22] <cnd> apw, but those numbers are *way* beyond the max
[17:22] <cnd> so something seems wrong
[17:23] <sforshee> cnd, http://pastebin.ubuntu.com/911758/
[17:23] <cnd> apw, oh, I think I know what's going on with those numbers
[17:23] <cnd> the width values are supposed to be scaled, as best as possible, to device units
[17:24] <cnd> but often times the width values reported by the devices are in some random other unit
[17:24] <cnd> so a scale factor is devised
[17:24] <cnd> I would have rather seen evdev report the raw values from the device; that was a henrik decision
[17:26] <cnd> sforshee, there's still a lot going on, but this is a good baseline
[17:26] <cnd> so in the first packet there are two new touches
[17:26] <cnd> in the second packet there appear to be three touches
[17:27] <cnd> however, BTN_TOUCH is 0 and BTN_TOOL_TRIPLETAP is left at 0
[17:27] <cnd> I don't understand what is going on there
[17:28] <apw> cnd, could they be getting softer, cause the pressure is also 0
[17:28] <apw> could this literally be the screen bouncing off the touchpad ?  does the machine have a touchscreen too?
[17:28] <cnd> apw, could be, but the touches are still active
[17:28] <cnd> apw, touchscreen would be a different evdev node, but this doesn't have a touchscreen anyways
[17:28] <sforshee> apw, no touchscreen
[17:29] <apw> i was more thinking is the screen made of something that acts like fingers, obviously gloved hands don't work etc
[17:29] <cnd> it seems like the single touch events (BTN_TOUCH, BTN_TOOL_*) are not in sync with the mt events
[17:29] <cnd> which is bad enough
[17:29] <apw> cnd, i dee in the next packet we have 4 taps
[17:29] <cnd> yeah
[17:29] <sforshee> I do think there are magnets involved in the lid switch mechanism, which may be close to the touchpad
[17:30] <cnd> sforshee, does the cursor still move?
[17:30] <apw> then we move, drop to three touches (correctly), back to four, then lose the touch with them again
[17:30] <cnd> after this particular recording
[17:30] <cnd> because all the touches have ended
[17:30] <sforshee> cnd, it does now because I reloaded bcm5974
[17:30] <cnd> oh
[17:30] <sforshee> but it didn't after I killed evtest
[17:30] <cnd> hmmm
[17:31]  * apw wonders if he has any magnest to wave at his touchpad
[17:31] <cnd> heh
[17:31] <apw> cking, you have magnets i bet ... do they affect touchpads to you know?
[17:31] <cnd> sforshee, I would send a note to henrik, and cc linux-input, asking about this behavior
[17:31] <cnd> I think others have seen it
[17:31] <cnd> but I can't seem to find any emails
[17:31] <cking> apw, I can find some... let me see what the kids have
[17:32] <apw> oh i have a fridge magnet, let me try that
[17:32] <cnd> sforshee, there seem to be two issues:
[17:32] <apw> this machine has an ssd so i should keep the disk contents :)
[17:32] <cnd> 1. the driver is not in sync between mt and st data
[17:32] <cnd> 2. has anyone looked into this already, is there a fix or a workaround?
[17:32] <cking> apw, so what do you want me to try then?
[17:32] <apw> cking, does it affect your touchpad at all
[17:33] <cking> here goes..
[17:33] <apw> doesn't on mine (found a ladybird on the fridge)
[17:33] <sforshee> apw, I'm failing to get a reaction from the touchpad using a magnet
[17:33] <cking> apw, no, but my HDD is now wiped ;-)
[17:33] <cnd> sforshee, try taking the screen of another laptop and hovering it over the trackpad?
[17:33]  * cking saunters off, was on at 7am..
[17:33] <cnd> maybe the LCD is doing it :)
[17:34] <apw> cnd, you have a separate one of those don't you?
[17:34] <cking> cnd, bet the speaker magnets in the LCD are affecting it
[17:34] <apw> cking, well except they don't on yours at least
[17:34] <cnd> apw, you mean a magic trackpad?
[17:34] <cnd> I could try that
[17:34] <apw> yeah that is likely similar device is it not
[17:35] <apw> i guess the trackpads are metal whereas mine may not be, so it may have more effect there
[17:35] <cnd> apw, ooo!
[17:35] <apw> cnd, it does vomit for some time either side doesn't it
[17:35] <apw> oooo ! ?
[17:35] <cnd> I got stuff when waving my MT across the top of my macbook lid
[17:35] <cnd> where the magnets are
[17:36] <apw> there are serious magnets in there
[17:36] <cking> http://www.gizmag.com/100-tesla-pulsed-magnet/21946/
[17:36] <cking> 100 tesla magnet will do
[17:36] <apw> another apple special then, their own trackpad is affected by the magnets they use to close the box
[17:36] <cnd> actually, it does it to the screen too
[17:36] <cnd> so it may not be the magnets
[17:36] <apw> cnd, i suspect thats not normal for other touchpad types
[17:37] <sforshee> apw, cnd: I can get events by holding a macbook pro near the macbook air touchpad
[17:37] <cnd> apw, hard to tell
[17:37] <apw> sforshee, so if you shove two or three sheets of paper in the gap and close/open does it do that
[17:37] <apw> we might be able to tell if its magnets (longer range) or plastic coating touching (short/zero) range
[17:37] <sforshee> apw, yes, when the lid is very close to closing I start getting some events
[17:37] <cnd> sforshee, I wonder if you add a resume hook to the driver to reset the state if it will fix things?
[17:38] <sforshee> basically it seems to happen at the point where the lid tries to snap closed
[17:38] <apw> cnd, should we not worry they could make 'valid' events and do something awful like close or move a window
[17:38] <cnd> hmm... good point
[17:38] <apw> like needing to disable the touchpad stream as soon as the lid event starts or something?
[17:38] <cnd> yeah
[17:39] <cnd> I don't know exactly how you would do that though...
[17:39] <apw> sforshee, can we tell when the lid event occurs, ie does the machine suspend if you close it reallly really slowly
[17:39] <apw> cnd, well OSX must be able to cope, so likely the lid event is in before the interferance starts
[17:39] <apw> sforshee, as a test maybe you could do something like close the lid in glacial time
[17:39] <apw> and see if it triggers before the events start
[17:39] <cnd> apw, yeah, probably
[17:40] <cnd> apw, but how could you code that up in a linux driver
[17:40] <cnd> ?
[17:40] <apw> you'd need to let the two kernel dirvers know about each other
[17:40] <cnd> I don't know if there's some way the bcm5974 driver can listen for lid events
[17:40] <apw> which is vileness extreme
[17:40] <cnd> yes
[17:40] <mjg59> Not trivially
[17:40] <mjg59> You could add a notificaiton chain
[17:40] <cnd> mjg59, ahh, should have pinged you earlier :)
[17:40] <mjg59> Or you could push it out to userspace
[17:40] <apw> yeah its bound to be a violation of about 20 layering
[17:41] <cnd> mjg59, if you pushed it out to userspace you might have race conditions
[17:41] <mjg59> Have a udev helper fire on the lid event and disable any USB input devices that are flagged as non-removable
[17:41] <cnd> mjg59, how could you be sure the bcm5974 driver will get it in time?
[17:41] <mjg59> cnd: It's going to be racy on a multi-threaded system in any case
[17:41] <cnd> I'm not meaning issues between cores
[17:41] <cnd> I mean issues in time
[17:41] <apw> i think if it even does it of course, you would have to have the MT driver check before emitting any packet
[17:42] <apw> which would mean looking at something global and shared in the kernel, which stinks
[17:42] <cnd> like, the event reaches userspace, userspace processes it and turns the touchpad off in 100 ms
[17:42] <cnd> but that's already too late
[17:43] <cnd> I suppose my theory is that keeping things in kernel will reduce the time enough that it is more reliable
[17:43] <apw> we'd need to confirm somehow the order of the events, is there anything we hear of in time even
[17:43]  * cnd wonders how we haven't seen this before
[17:43] <apw> http://askubuntu.com/questions/91534/disable-touchpad-while-the-lid-is-down
[17:44] <apw> sforshee, you might be able to use that to get a hint as to whether the lid closes before the problem happens if you arn't to quick :)
[17:44] <cnd> I bet because of behavior changes in X
[17:44] <sforshee> so I'm pretty sure at this point it is the magnet, as I can hold a macbook pro close to the touchpad but not touching and get touchpad events
[17:44] <cnd> apw, that will only turn off the device at the X level
[17:45] <sforshee> I also know I can suspend the machine without completely closing the lid
[17:45] <cnd> maybe that's good enough though
[17:45] <cnd> sforshee, you can evtest both the bcm5974 and the lid switch devices
[17:46] <cnd> and compare the timestamps
[17:46] <apw> sforshee, when does the backlight go off relative to the problem occuring too
[17:46] <cnd> see how close they get with fast lid closures
[17:46] <ohsix> it can be emi too, though i dunno much of which would be near where the magnets are
[17:46] <apw> sforshee, what cnd suggests makes the most sense.
[17:46] <ohsix> my friend could make his macbook reboot by putting his phone next to his computer, they can be pretty sensitive :D
[17:46] <apw> lets see if they are in any sort of sensible order
[17:46] <sforshee> apw, it goes off earlier -- there seems to be something else in play for the lid event
[17:47] <cnd> sforshee, what goes off earlier?
[17:47] <sforshee> I can't make the machine suspend by holding the MBP closeby
[17:47] <sforshee> cnd, the backlight
[17:47] <cnd> oh
[17:47] <apw> sforshee, isn't that triggered by the lid event ?
[17:47]  * apw thinks we need the double evtest comparison
[17:48]  * sforshee is getting it right now
[17:48]  * cnd whipers
[17:48] <cnd> whispers...
[17:48] <cnd> I ruined it
[17:51] <sforshee> the lid switch event happens first, by about 400 ms
[17:51] <apw> ok so we at least have something to tell us when we need to ignore it
[17:51] <cnd> sforshee, including when you try to close it as fast as possible without breaking it?
[17:51] <apw> sforshee, i assume it unhappens after the flood stops too yes?
[17:51] <sforshee> cnd, I was just about to say, let me try again closing the lid as quickly as possible
[17:51] <ohsix> sforshee: was the input periodic or just fast/seemingly random
[17:52] <cnd> ohsix, http://pastebin.ubuntu.com/911758/
[17:52] <apw> ohsix, its a bunch of fat fingers reported all over the touchpad
[17:52] <apw> cnd, this feels very familiar you know, is the matrix broken ?
[17:52] <ohsix> interesting, it could be the lcd
[17:53] <apw> ohsix, i think experimentation says its the lid in some sense, which bit isn't so interesting
[17:53] <sforshee> rats, now I start getting touchpad events about 7 ms before the lid event
[17:53] <cnd> ugh
[17:53] <apw> sforshee, well ... remember we have to get them out into userspace
[17:53] <apw> who puts the timestamps on them, the uspace daemon ?
[17:53] <sforshee> apw, yes
[17:54] <sforshee> but they're certainly very close
[17:54] <cnd> apw, that doesn't even matter now
[17:54] <cnd> the lid switch is occurring *after* the bad touches
[17:54] <apw> cnd, where is the timestamp we see added
[17:54] <ohsix> right but a magnet isn't going to capacitively couple with a touchpad, it may induce currents but only as it moves (no matter how strong it is)
[17:54] <cnd> apw, hmm?
[17:54] <cnd> I didn't understand the question
[17:55] <apw> cnd, we have two streams of data with timestamps, who put the stamps on them, the kernel or the evtest app
[17:55] <cnd> apw, the kernel
[17:55] <sforshee> apw, 7 ms seems long enough that I doubt they're getting reordered anyway
[17:55] <ohsix> some heuristics in the touchpad firmware are probably going bonkers because it's coupling with something in the display
[17:55] <apw> ohsix, yep i think we know that ... what we don't know is how to stop it
[17:56] <apw> given the lid is not going to change compisition
[17:56] <ohsix> right :] it's just not a magnet
[17:56] <ohsix> you may be able to control SSC or something in the lcd panel that could affect it tho
[17:57] <apw> sforshee, it may be worth looking for reports of whining on osx about closing the lid and it being bad
[17:57] <apw> (if you do it fast)
[17:57] <cnd> btw, my MT sees touches even when the screen is off
[17:57] <sforshee> ohsix, there seems to be a magnet in the lid that holds the lid down when it's closed
[17:57] <cnd> so merely turning the screen off isn't a fix either
[17:57] <sforshee> so when you close the lid it will be moving, period
[17:57] <ohsix> cnd: what model is it?
[17:57] <sforshee> macbook air 4,1
[17:57] <cnd> ohsix, I was playing with a magic trackpad and a macbook 5,1 (I think)
[17:58] <apw> cnd, yeah wasn't thinking we want to turn off the screen, i was thinking we want to disable the touchpad
[17:58] <cnd> yeah, I was just throwing it out there
[17:58] <cnd> in case anyone else thought about it :)
[17:59] <apw> cnd, that link i posted is from something with MSI hotkeys, doing the same sort of thing
[17:59] <cnd> apw, I missed the link
[17:59] <cnd> oh, nm
[17:59] <cnd> I got it
[17:59] <apw> sforshee, so i assume if you turn off 'suspend when closed' we could get a trace then which would tell us if its the screen moving or it being closed at all is the issue
[17:59] <sforshee> cnd, the root problem though is that userland is in a confused state though, right? so can we reset the userland state after s3?
[18:00] <apw> sforshee, what if it quad clicks on something
[18:00] <cnd> sforshee, maybe
[18:00] <sforshee> apw, true
[18:00] <apw> cnd, actually arn't the touches 'really really big' ?
[18:00] <cnd> not all of them
[18:00] <apw> cnd, and doesn't osx have "stop palms from doing bad things" support ?
[18:00] <apw> maybe they get away with it cause of that
[18:00] <sforshee> apw, cnd: actually I've noticed a few times that the dash is up after S3 when I'm sure it wasn't before, so that's probably caused by these events
[18:00] <cnd> maybe
[18:01] <cnd> heh
[18:01] <apw> eeek
[18:01] <apw> sforshee, so maybe try the thing they do in there and see if it helps any
[18:01] <mjg59> Ok, easier way:
[18:01] <mjg59> Have the X server tag all input devices as internal or external (or unknown)
[18:01] <mjg59> The X server is single threaded, so can't race against itself
[18:02] <mjg59> On lid close, stop listening to internal events
[18:02] <ohsix> the magnets are pretty far away from the camera
[18:02] <mjg59> Doesn't help in the case where the events are out of order, but...
[18:02] <apw> mjg59, sounds logical, at least there it has only a 7ms window instead of 'all night' to get events
[18:02] <cnd> mjg59, there's no real way for one X input module to listen to events from another
[18:02] <ohsix> here's the stuff at the top of the frame http://guide-images.ifixit.net/igi/jcpGIlZE1LLllEoQ.medium http://guide-images.ifixit.net/igi/fGqAJCnKVgROdlkl.medium
[18:02] <cnd> IIRC
[18:03] <cnd> and part of the state that needs to be maintained is in the X synaptics module
[18:03] <cnd> however, the X server could turn off an input driver
[18:03] <ohsix> heh what mjg59 suggests is probably a good idea for all machines :D (if there's a reliable indication when the lid is working)
[18:04] <cnd> mjg59, that still doesn't resolve the problem of fast lid closure
[18:04] <cnd> where the lid event occurs after the bad touches
[18:04] <apw> cnd, we actually can't program round bad h/w design
[18:04] <apw> cnd, if you close it fast and it presses random shit, there is little we can do about it
[18:04] <cnd> yeah
[18:05] <apw> i know you don't want to hear an apple product has bad design, but ... i suspect it does
[18:05] <sforshee> i literally slammed the lid, it will rarely be closed that fast
[18:05] <cnd> sadly, I can't test this
[18:05] <cnd> because my macbook won't suspend/resume properly
[18:05] <cnd> ok, then maybe it will be good enough
[18:08] <apw> sforshee, the joys of work owned test key :)
[18:08] <apw> kit
[18:10]  * sforshee goes to find some food
[18:49] <ppisati> unity2d can finally enjoy the launcher on the second screen... @$#%@#<EMAIL_ADDRESS>[19:08] <beata|lemur> I get an error message when I run the 'git rebase --onto origin/master origin/master@{1}' command listed on the kernel git guide wiki, section 'Maintaining local changes': 'fatal: Needed a single revision' 'invalid upstream origin/master@{1}'
[19:10] <apw> ogasawara, that testing came in, postitive so am about to push those hyper-v patches
[19:10] <ogasawara> apw: ack.  go ahead and push, I'll wait to rebase to 3.2.14 till after you've pushed.
[19:12] <apw> ogasawara, ok done, thanks
[19:13] <tgardner> ogasawara, how's the Q rebase going ?
[19:13] <ogasawara> tgardner: just finishing it up and am about to test build
[19:46] <Kano> apw: could you touch the missing include file maybe? even a 0 size file is enough to fix compilation issues
[20:07] <Kano> did somebody else notice that kernel 3.3+ boots faster than 3.2?
[20:07] <Kano> similar speed to 2.6.38 which was faster than .39+
[20:09] <Kano> debian 3.2: 8s, mainline u config: 7s, since 3.3: 5s
[20:12] <Kano> i boot wheezy btw ;)
[20:31]  * tgardner -> EOD
[21:16]  * ppisati -> reboot
[22:00] <Kano> does anybody know why booting via efi is slower
[22:01] <lesshaste> is there a workaround for https://bugs.launchpad.net/ubuntu/+source/linux/+bug/884210 ?
[22:01] <ubot2> Launchpad bug 884210 in linux "PCI/internal sound not working randomly, random hangs: "cannot set freq 16000 to ep 0x86" shown in syslog" [High,Confirmed]
[22:02] <lesshaste> oh is there an easy way to test a more recent ubuntu kernel?
[22:02] <lesshaste> I am on oneiric
[22:10] <ayan> all: what determines which modules are loaded at boot time?  i notice /etc/modprobe.d/* but those files seem to determine what isn't loaded more than what is.
[22:11] <Kano> udev
[22:11] <Kano> lesshaste: which gfx card
[22:13] <lesshaste> 01:00.0 VGA compatible controller: nVidia Corporation NV44 [Quadro NVS 285] (rev a1)
[22:13] <lesshaste> Kano, ^^
[22:13] <Kano> nvidia binary used?
[22:13] <lesshaste> I just switched to nouveau
[22:13] <lesshaste> to see if it would help
[22:13] <Kano> because you need hacks for newer kernels
[22:13] <lesshaste> I still get  cannot set freq 16000 to ep 0x86
[22:14] <lesshaste> I just want to be able to use the quickcam without it destroying my compute r:)
[22:14] <ayan> Kano: i suspected udev might do it but -- for example -- i have psmouse loaded but i don't see it anywhere in any of the udev configuration files.
[22:14] <Kano> alias:          serio:ty05pr*id*ex*
[22:14] <Kano> alias:          serio:ty01pr*id*ex*
[22:14] <Kano> you see with modinfo psmouse
[22:15] <lesshaste> Kano, are there no kernels in backports?
[22:15] <lesshaste> Kano, that I can use in 11.10
[22:15] <Kano> i dont use ubuntu
[22:15] <lesshaste> we are in #ubuntu-kernel!? :P_)
[22:16] <Kano> KERNEL
[22:16] <Kano> i recompile it or use mainline ones


[11:16] <Saviq> pstolowski, bug #1154207 :P
[11:17] <pstolowski> Saviq, uhm.. seeing that you commented on it on 2013-11-14 makes me sad
[11:22] <Saviq> pstolowski, I suppose it should be possible for us to override the logger to include timestamps or something - but I *really* feel this should be upstart's job... suppose journalctl would give us that
[11:25] <pstolowski> Saviq, is it realistic to expect any upstart development?
[11:25] <Saviq> pstolowski, no
[11:26] <Saviq> especially since the bug was not received kindly I'd say
[11:26] <pstolowski> i think there was a session on UOS about fully replacing upstart
[11:26] <pstolowski> (long-term)
[11:32] <pstolowski> Saviq, i'd prefer an imperfect solution right now than a perfect one in 1 year from now
[11:32] <Saviq> pstolowski, sure, I know
[11:55]  * greyback reboots to try fix microphone
[12:02] <greyback> curses, powertop autotune on startup screws up my mic
[12:02] <greyback> or more correctly, enaling power management for my intel sound card breaks my mic
[17:28] <mhall119> willcooke: Saviq: ChrisTownsend: bregma: FYI, I wrote down all my workarounds for using Unity 8 on my laptop: http://mhall119.com/2016/05/dogfooding-unity-8/
[17:33] <ChrisTownsend> mhall119: Very cool, thanks for that.
[17:39] <Saviq> mhall119, one correction: yakkety isn't a good target for this, we're not releasing into it atm, just to overlay for both vivid and xenial
[17:39] <Saviq> mhall119, also, the hybris silo is https://requests.ci-train.ubuntu.com/#/silo/31
[17:40] <Saviq> not 53 (I believe Simon moved it over)
[17:41] <bregma> URL bookmarked for reference
[17:41] <greyback> ditto
[17:42] <mhall119> Saviq: thanks, I'll make those updates
[17:44] <bregma> heh, we often play ci-train whack-a-mole with silos, which is one reason we avoid making them public (the other is that the software in them has not yet passed testing, pretty much by definition)
[18:23] <willcooke> nice one, thanks mhall119 - are there any bugs to go with it already?
[18:36] <mhall119> I filed some against webbrowser-app already, but there are more I need to file
[19:44] <drench> unity always crashed
[19:51] <Saviq> ohkay
[19:54] <ltinkl> I think he crashed