[07:46] <ppisati> yawn
[09:02] <apw> ppisati, do we still test pandas with 3.13?  infinity was trying to switch the omap4 images to generic kernel and was having trouble with framebuffer and network?  
[09:02] <apw> and ... morning
[09:02] <smb> apw, mourning morning
[09:03] <apw> i normally am mourning bed at this time of the morning
[09:03] <ppisati> apw: i tried that last week, network was definitely, but didn't test the framebuffer
[09:03] <smb> apw, lazy git
[09:03] <apw> was definalty working or not working
[09:03] <ppisati> apw: working
[09:05] <ppisati> apw: http://paste.ubuntu.com/6807371/
[09:05] <apw> ppisati, prolly need to get you and infinity together next week to figure out his pain in the installer
[09:06] <ppisati> apw: let me see the framebuffer
[09:06] <apw> ppisati, perhaps upgrade it to -5 as well, i am amazed it works so well for you -4 being a bit of a turkey
[09:06] <ppisati> eh
[09:06] <ppisati> apw: let's see -5
[09:07] <apw> -4 had a hideous brown paper bag in a core allocation primative, it is very bad generally :)
[09:18] <ppisati> apw: flag@panda:~$ uname -a
[09:18] <ppisati> Linux panda 3.13.0-5-generic #20-Ubuntu SMP Mon Jan 20 19:57:47 UTC 2014 armv7l armv7l armv7l GNU/Linux
[09:18] <ppisati> flag@panda:~$ sudo mii-tool 
[09:18] <ppisati> eth0: negotiated 1000baseT-HD flow-control, link ok
[09:19] <ppisati> fb seems to be broken though
[09:19] <ppisati> my bet is that infinity has an old boot loader
[09:20] <apw> ppisati, thanks at least we know it isn't systemic, is the boot loader upgradble ?
[09:20] <ppisati> apw: manually repleaceable? yes
[09:20] <ppisati> apw: do we do it automatically? AFAIK no
[09:21] <ppisati> apw: but let's check when he appears
[09:25] <ogra_> we dont do it automatically ... i would have loved to back then but always got pushback "uboot is like BIOS ... we dont replace the BIOS either on upgrades"
[09:26] <ppisati> ogra_: oh, there you are, hello Olli :)
[09:32] <ogra_> :)
[09:36] <apw> ppisati, sounds like a plan to me, thanks
[10:47] <apw> henrix, this set of fixes for CVE-2013-0160, as it does not do the INOTIFY bit due to the lack of that feature in that release, how does it avoid the issue
[10:49] <henrix> apw: since this fsnotify isn't in lucid, the user can't actually monitor a ptmx without reading atime/mtime
[10:49] <henrix> hmm....
[10:50] <henrix> but now that i think about it, i may be wrong
[10:50]  * henrix goes back into old code to check if this is actually true
[10:51] <apw> fsnotify is there, the nonotify flag isn't, right ?
[10:52] <henrix> yes, it is
[10:52] <apw> henrix, worse it seems to have inotify and fsnotify "unmerged" in there, gah
[10:53] <henrix> so... ok, let me take a closer look at this.  i guess i assumed something that is not true :/
[10:53] <apw> henrix, though you also tested it, so perhaps the test is bogus, not sure
[10:54] <apw> henrix, in better news the bit which introduces the very basic support looks pretty easy to backport (commit ecf081d1a73b077916f514f2ec744ded32b88ca1)
[10:54] <henrix> apw: yes, i've used the PoCs and they don't work with these backports. *however* the PoCs don't use fsnotify, they read the atime
[10:55] <apw> henrix, thoguh it has a fix applied on top to change the constant (12ed2e36c98aec6c41559222e311f4aa15d254b6)
[10:56] <apw> henrix, ahh that would explain it then, so i think those two are trivial to backport, if we ignore the rest of the functionality that is for, ie all the other bugs FANONOTIFY is meant to fix :)
[10:56] <apw> though in the backport the inotify bits need to be in the "if"
[10:57] <henrix> apw: yep, makes sense.  sooooo.... let me send myself a NACK and go take another look at this
[10:58] <henrix> apw: and thanks for keeping your eyes open!
[10:59] <apw> i've replied with the bits of info here summarised, and ... that is why we do peer review of these things, as it is unrealistic to expect people to never make an error, never happen
[11:00] <henrix> cool!  so, i'll work on these 2 additional backports and re-tests.
[11:00] <henrix> thanks ;)
[11:00] <apw> henrix, wonderful indeed
[11:01] <apw> there is an inotify_watch oro somethign which ought to allow you to confirm it doesn't work
[11:02] <apw> inotifywait -m /dev/ptmx
[11:02] <apw> i think that is the baby which should show it
[11:02] <apw> henrix, ^^
[11:03] <henrix> apw: ah, nice. i'll use that for additional testing.
[11:10]  * apw tries to confirm that works
[11:10] <apw> as alll my kernels are fixed :/
[11:11] <apw> seems that someone has been toooo efficient
[11:12] <brendand> does anyone here know much about hdd parking? we're trying to test it and it seems atm as if there's a lot of different implementations, only some of which are supported
[11:12] <brendand> hdaps being one that works
[11:12] <apw> brendand, do you mean parking as in "oh shit i am falling and likely there will be some hitting real soon, park NOW"
[11:13] <apw> brendand, and if so, then not much is know but yes, it is a fragmented secret sauce part of the h/w eco system
[11:14] <brendand> apw - what other kind of parking is there :/ ?
[11:15] <apw> well parking is just then "putting the heads away", you do this on poweroff of the drive, sometimes on idle
[11:15] <apw> and in some cases on "oh shit i am falling"
[11:15] <apw> i would call it "emergency HDD parking" or something to be clear you mean that 
[11:15] <brendand> apw - do you know any other implementations (that are supported in ubuntu)?
[11:16] <apw> but cirtainly it has never been something we have investigated, so no i don't think we do know
[11:16] <apw> i doubt any are configured automatically correctly
[11:16] <apw> as from even the hdaps for IBM stuff is randomly model specific, gah what a mess
[11:26] <brendand> apw, yes - somebody needs to take the initiative to make a standard interface for it
[11:49] <apw> henrix, ok ... confirmed that without your patches at all lucid shows the inotify issue using the test above
[11:50] <henrix> apw: ack, thanks. i haven't reached that point yet -- still building test kernel, and will re-test in a few minutes
[11:51] <apw> henrix, figured i would test an unfixed kernel first :)
[11:52] <henrix> yep, makes sense :)
[11:59] <apw> henrix, as the lucid installs i have are server only, i ran that on the console and then ssh'd in
[12:02] <henrix> apw: i've just tested in a vanilla lucid VM as well and confirmed your test result ;)
[13:12] <apw> henrix, yay
[13:13] <henrix> apw: hey...?
[13:13] <henrix> what's up?
[13:21] <apw> henrix, nothing: yay == poisitive sounds for your confirmation of my test result
[13:21] <henrix> apw: ahh! :)
[13:22] <henrix> apw: and i've just finished my testing with v2 of the patchset.  just finishing the cover letter and will send it in a bit
[13:26] <apw> henrix, sweet
[13:35]  * henrix curses AUFS
[13:41]  * Kaloz is wondering why anyone would use aufs
[13:41] <henrix> beats me :)
[13:42]  * Kaloz handles henrix the note about the current year ;)
[13:43] <Kaloz> we never adopted unionfs/aufs, went straight to overlayfs from mini_fo
[13:58] <rsalveti> apw: updated tree for flo (new nexus 7): http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-trusty.git;a=shortlog;h=refs/heads/flo
[13:59] <rsalveti> apw: tested and working fine with my 4.4 based image, so can already be pushed to the archive
[13:59] <rsalveti> apw: just need a new release + meta
[14:03] <rsalveti> apw: grouper rebase for kitkat: http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-trusty.git;a=shortlog;h=refs/heads/grouper-rebase-kitkat (also tested with 4.4)
[14:03] <rsalveti> apw: but that would need to go into a PPA for now
[14:04] <apw> rsalveti, ack
[14:10] <apw> rsalveti, do i need to interact with someone to upload the flo one or can i dump it in -proposed
[14:11] <rsalveti> apw: just dump it in proposed
[14:11] <rsalveti> argh, wrong monitor (contro + w) :-)
[14:15] <apw> heh focus fail, a common problem with unity in my experience
[14:18] <ogra_> we just need to add eyetracking via webcam ... and use focus follows eyes
[14:19] <ogra_> trivial stuff :P
[14:20]  * henrix sends v2 of CVE fix and runs
[15:35] <apw> rsalveti, ok flo in the queue
[15:41] <apw> rsalveti, do this grouper rebase is just to 3.1.10 its not a 3.4 rebase
[15:43] <apw> rsalveti, so ... is still a 3.1 kernel then ... just checking
[16:12] <rsalveti> apw: yeah, still 3.1, just rebase on top of the 4.4.2
[16:12] <rsalveti> changes
[16:12] <apw> ok
[16:51] <apw> rsalveti, ok uploaded grouper to ckt PPA
[17:11] <rsalveti> apw: great, thanks