[02:56] <unixabg> apw: Greetings, I have a small diff here http://paste.ubuntu.com/12189919/  but it would seem
[02:57] <unixabg> that something else is not right yet. I believe I understand all the code you added and I would like to 
[02:59] <unixabg> chat when you and I can both be online
[03:03] <unixabg> Ok I just tested again and it did not boot, hmmm.
[03:07] <unixabg> Odd with quiet not on cmdline it fails but with it on cmdline it boots. Another hmmm.
[03:09] <unixabg> I am not fully sure, but I can manually mount filesystem.squashfs and then exit busybox
[03:10] <unixabg> when testing. Oh and so the patch works unless you remove quiet from boot param. To me that is
[03:12] <unixabg> unrelated for now. But in busybox initramfs it does not allow me to mount multiple lowerdir stack
[03:12] <unixabg> so I am not sure what is going on. Thanks for your help and I hope this information assists
[03:12] <unixabg> somehow.
[08:45] <apw> moin
[08:46] <apw> ok that is odd, something wrong with the verbose code perhaps ...
[09:42] <tseliot> apw: hi, it's been about 5 years since I set up my last git branch on http://kernel.ubuntu.com, and, as a result, I can't remember how to make a branch public, how pull requests work, etc. Is there a wiki page about it?
[09:42] <apw> tseliot, though you could go through all that, you might just want to use a personal LP git repo now
[09:43] <apw> tseliot, as we are meant to be using LP for such things in principle
[09:43] <tseliot> apw: and could I send a pull request to a branch on http://kernel.ubuntu.com then? I need to update linux-firmware
[09:44] <apw> tseliot, yep location is no barrier to git
[09:44] <apw> git+ssh://tseliot@git.launchpad.net/~tseliot/ubuntu/+source/linux-firmware 
[09:45] <apw> or similar
[09:45] <apw> you can have multiple repos there with the addition of +git/name should that make sense to you 
[09:45] <tseliot> apw: excellent. Thanks a lot!
[09:46] <apw> tseliot, and obviously you have different ones for other source packages
[09:49] <tseliot> right
[12:11] <rtg> tseliot, any progress on wily fglrx ?
[12:11] <tseliot> rtg: no, sorry, I haven't looked into it yet but I will
[12:12] <tseliot> I need to finish some other work first
[12:12] <rtg> tseliot, no pressure, but it is the last package that needs to work before we promote a 4.2 based kernel to -proposed
[12:13] <tseliot> rtg: ok, I'll do it either later today or tomorrow
[12:59] <tseliot> sforshee: hi, shall I send a pull request to wily or to master?
[12:59] <apw> isn't master upstream ?
[12:59] <apw> so it depends which you are proposing it for
[13:00] <rtg> tseliot, it should be against wily initially, then we'll have to do the same for trusty
[13:00] <rtg> to support the HWE kernel
[13:00] <tseliot> oh, so master = upstream ?
[13:00] <tseliot> ok
[13:00] <apw> iirc yes i think he said that
[13:01] <tseliot> then wily it is
[13:01] <apw> sforshee | tseliot: btw you'll want to use the wily branch, master just tracks upstream
[13:01] <apw> thought i saw that somewhere
[13:01] <tseliot> I'm sure I missed it, my eyes are very tired these days
[13:02] <apw> tseliot, :)
[13:24] <tseliot> apw, sforshee: I've just made a pull request, if I screwed that up, just let me know and I'll try again ;)
[13:46] <sforshee> tseliot: I haven't seen an email for your pull request yet
[13:47] <tseliot> sforshee: how does that work? Sorry, I'm used to github when it comes to pull requests
[13:49] <Odd_Bloke> bjf: Could you attach /var/log/cloud-init.log to https://bugs.launchpad.net/cloud-init/+bug/1488507 please?
[13:49] <sforshee> tseliot: basically, push the thing you want pulled to your public repo, run 'git request-pull ...', then put the output it spews into an email
[13:50] <tseliot> sforshee: oh, ok, shall I send the output to your email address and subscribe some other list?
[13:51] <bjf> Odd_Bloke, working on it
[13:51] <sforshee> tseliot: send it to kernel-team@lists.ubuntu.com, you can send to me too if you want but I'll see it there
[13:52] <tseliot> sforshee: ok, thanks
[13:52] <bjf> Odd_Bloke, done
[13:53] <Odd_Bloke> bjf: Thanks.
[13:54] <Odd_Bloke> bjf: Looks like we just/recently introduced that breakage; I've asked smoser to take a look.
[13:54] <bjf> Odd_Bloke, ack
[13:57] <tseliot> sforshee: ok, sent
[14:04] <Odd_Bloke> bjf: smoser is on it. :)
[14:18] <tseliot> apw, rtg: is this the repository with the kernel in the ppa that makes fglrx fail? git://kernel.ubuntu.com/ubuntu/unstable.git
[14:22] <rtg> tseliot, git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/wily master-next
[14:23] <rtg> tseliot, you can also get the kernel and headers from https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/ppa
[14:27] <tseliot> rtg: ok, thanks
[14:38] <arges> tjaalton: i915 question. If 4.2-rcX is broken, and 4.1 works (for external monitors), before bisection are there out of tree patches I should try looking at first?
[14:40] <arges> drm-intel-nightly? is that the right tree or is it something else
[14:48] <Sarvatt> arges: yeah seeing if drm-intel-nightly works would be the next step to see if its already fixed for 4.3
[14:48] <arges> Sarvatt: thanks, giving that a shot now.
[14:49] <tseliot> rtg: I've found what broke fglrx on i386 (d5cea9b0af1509f170337ba8f47160d0699ff374). I'm testing my patch, and I plan to upload soon
[14:49] <rtg> tseliot, ack, thanks
[14:57] <arges> Sarvatt: ok drm-intel-nightly seems to work, do i need to report anything to enusre that makes it into the wily/4.2 kernel?
[14:59] <tjaalton> arges: what's the bug?
[14:59] <tjaalton> and which intel generation
[14:59] <Sarvatt> what 4.2 was broken? rc7 had some problems that got fixed in rc8
[15:00] <arges> tjaalton: oh i noticed on my x220 using the 4.2.0 wily kernel caused the external monitor to not display correctly. internal only mode worked fine
[15:00] <tjaalton> also check drm-intel-next, which is a bit old at this point but should be a good bisection point if nightly works
[15:00] <tjaalton> ah
[15:01] <tjaalton> it's been filed already, if you mean flickering?
[15:01] <arges> yea the external montior was flickering when I set it to span mode. but internal only on the x220 panel worked fine
[15:01] <arges> but drm-intel-nightly works as well as 4.1.0/wily kernel
[15:02] <tjaalton> https://bugs.launchpad.net/bugs/1421575
[15:02] <tjaalton> that's weird if wily kernel works, since this bug is on same hw and still broken on wily
[15:03] <arges> yea I think my failure is slightly different. I see more stability than the entire screen looking like that in the bug
[15:05] <bjf> jsalisbury, don't we want the fix for LP: #1486146 in lts-utopic also ?
[15:12] <jsalisbury> bjf, yes, I can add the bug task in the bug
[15:13] <bjf> jsalisbury, i'll just make it so
[15:13] <jsalisbury> bjf, great, thanks
[15:21] <tseliot> apw, rtg: fixing that got me into a new GPL-only issue :/ http://paste.ubuntu.com/12193123/
[15:22] <rtg> tseliot, yeah, I got about that far before I left on vacation (then completely forgot about it)
[15:24] <rtg> tseliot, commit 5e907bb0459399b0d1cc8d4c7e9f363a995b748a did that in 4.2-rc1
[15:24] <tseliot> rtg: right, although fglrx doesn't seem to use it directly
[15:24] <apw> xsave uses it
[15:25] <tseliot> apw: right, I only grepped xsave_state
[15:25] <tseliot> sigh
[15:27] <rtg> tseliot, is there a way to have i386 do the same thing as amd64 (which appears to work)
[15:32] <tseliot> rtg: it checks if static_cpu_has(X86_FEATURE_XSAVE), or if static_cpu_has(X86_FEATURE_FXSR), or it uses another solution if neither is true: http://paste.ubuntu.com/12193182/
[15:33] <tseliot> my eyes are leaving me already...
[15:37] <jsalisbury> **
[15:37] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:37] <jsalisbury> **
[16:12] <apw> it sounds like it needs an rtg patch saying this limits other simple things like xsave to be _GPL
[17:00] <jsalisbury> ##
[17:00] <jsalisbury> ## Meeting starting now
[17:00] <jsalisbury> ##
[18:57] <_ruben> bah .. wished the linux kernel features would have better documentation .. am rather interesting in the vti stuff (virtual tunnel interface), but docs are *really* sparse .. and yes, this obviously not an ubuntu issue, but just needed semi-ontopic place to vent ;)
[19:00] <apw> kernel documentation is for wimps :)
[19:03] <_ruben> the only "docs" i found so far are the commit logs, which have some bits of usefull info in 'em, just not enough to make for a working poc :)
[19:04] <ohsix> there are names in MAINTAINERS you could email
[19:07] <ohsix> what do you acttually want to know
[19:08] <_ruben> ohsix: how to setup a functional vti tunnel :)
[19:08] <ohsix> it looks similar to all the tunnel/encap stuff
[19:11] <_ruben> http://paste.ubuntu.com/12194539/
[19:12] <_ruben> this is almost direct copy of one of those commit logs
[19:14] <ohsix> http://git.kernel.org/cgit/linux/kernel/git/shemminger/iproute2.git/tree/ip/link_vti.c
[19:15] <ohsix> you know about 'ip' and 'tc' right
[22:44] <teward> hello, from #ubuntu, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/989191 was mentioned, and that it may have a bad 'fix released' status - anyone on the kernel team want to check if that's the case?
[22:45] <teward> or nevermind, TJ- already did :)
[22:45] <teward> i sometimes forget people are in multiple chans :)
[22:46] <TJ-> :)
[22:46] <TJ-> I've added a commentary
[22:46] <mjg59> Reasonably convinced it's not a linux bug
[22:46] <mjg59> I spent a while working on that years ago
[22:47] <teward> (y'all don't mind if I lurk here do you?)
[22:48] <TJ-> There are several reports that the model works fine as far back as 12.04
[22:48] <TJ-> However, there are several confirmed reports that disconnecting the internal battery, and/or re-insulating its leads, solves the issue. That suggests a power starvation issue
[22:51] <mjg59> My recollection is that whether it turned off or not depended on whether it was above a specific temperature when you pulled the power
[22:52] <mjg59> Something changed the thermal trip level and it immediately powered off
[22:54] <TJ-> Some users report acpi_osi="Microsoft Windows XP" solves it, which makes sense. mjg59  I suppose it's worth looking at the DSDT
[22:55] <mjg59> Yeah, I don't have access to one any more
[22:55] <mjg59> Oh, I was looking at the 31e, not the a
[22:55] <mjg59> http://mjg59.dreamwidth.org/11750.html
[22:56] <TJ-> I've just disassembled the one attached to the g.k.o report
[22:56] <TJ-> s/g.k.o/b.k.o/
[22:57] <TJ-> I'll ask our user to dump the ACPI once he's fixed the corrupted file-systems