[08:32] <smb> morning .+
[09:04]  * smb has the "feeling" jjohansen is still awake
[09:04] <jjohansen> no not at all
[09:04]  * jjohansen sends emails in his sleep
[09:05] <smb> I am not sure this is a feat or curse...
[09:05] <smb>  :)
[09:05] <jjohansen> hehe, definitely a curse
[09:05] <smb> Even half-asleep those emails usually get the "what the heck did you try to say with that" reply. :)
[09:07] <jjohansen> hehe, yeah I have been told I am blibbering idiot and incoherent all to often
[09:08] <smb> :D At least I am not alone there.
[10:51] <ppisati> lp 903346
[10:51] <ubot2> Launchpad bug 903346 in linux "On omap, CONFIG_DEFAULT_MMAP_MIN_ADDR needs to be set to 32768 per kconfig notes" [Medium,Confirmed] https://launchpad.net/bugs/903346
[10:52] <ogra_> seems we had serious luck over the last releases ...
[10:52]  * ogra_ would love to know when that was set wrongly 
[10:54] <ppisati> i think it has never been modified
[10:54] <ppisati> since we spun off arm from master
[10:58] <ogra_> ppisati, well, it was properly set once 
[10:58] <ogra_> in 2009 
[10:58] <ogra_> so somehow that didnt get carried over from the original omap config
[10:59] <ogra_> our luck was that procps' initscript runs early enough to set it to 32768, else we would have had non working binaries all over the place
[11:09] <ppisati> ogra_: and how did we discover it?
[11:09] <ogra_> armhf failed 
[11:10] <ogra_> well, procps failed on armhf ... which in turn made us look at the kernel defaults when fixing 
[11:14] <ppisati> ok
[13:25] <ogra_> smb, wrt enforcer ... binaries (all of them) get killed if not run as root when mmap_min_addr points to 64k
[13:25] <ogra_> so i would think it runs ... since thats the reason we found that this option was dropped from our kernel
[13:26] <smb> ogra_, By enforcer I meant the thing that runs before you get to the compile stage
[13:26] <ogra_> oh, that 
[13:26] <ogra_> well, i saw it on my ac100 kernel ... but thats built out of tree anyway
[13:27] <smb> Yep, not sure if was running for the topic branch. But if its just a safety feature to not drop it accidentally again
[13:27] <ogra_> yep, agreed
[13:28] <ogra_> though as long as procps gets executed early enough we wouldnt even notice
[13:28] <ogra_> (the upstart job that is)
[13:28] <smb> Which is a sort of "even worse"
[13:28] <ogra_> right
[13:29] <ogra_> we actually only noticed it because procps was screwed
[13:39] <ppisati> smb: the problem with the enforce as it is now
[13:39] <ppisati> smb: is that it doesn't enforce much
[13:39] <ppisati> # Default to 32768 on ARM, 65536 for everything else.
[13:39] <ppisati> ( ( arch armel | arch armhf ) & value CONFIG_DEFAULT_MMAP_MIN_ADDR 32768 ) | \ ( value CONFIG_DEFAULT_MMAP_MIN_ADDR 65536)
[13:40] <smb> ppisati, hmm. thats already there?
[13:40] <ppisati> ( ( arch armel | arch armhf ) & value CONFIG_DEFAULT_MMAP_MIN_ADDR 32768 ) |  ( ( !arch armel & !arch armhf ) value CONFIG_DEFAULT_MMAP_MIN_ADDR 65536)
[13:40] <ppisati> smb: yep
[13:41] <smb> The I wonder whether it is actually called...
[13:41] <ppisati> if i add the ( !arch armel & !arch armhf )... it should be ok
[13:41] <ppisati> yes it is
[13:41] <ppisati> the problem is the OR
[13:41] <ppisati> this one was false: ( ( arch armel | arch armhf ) & value CONFIG_DEFAULT_MMAP_MIN_ADDR 32768 )
[13:41] <ppisati> because CONFIG_DEFAULT_MMAP_MIN_ADDR = 64k
[13:42] <ppisati> while the second part was true, but didn't specify it wasn't for arm
[13:42] <ppisati> -> ( value CONFIG_DEFAULT_MMAP_MIN_ADDR 65536)
[13:42] <smb> hm, I read it as if armel or armhf then it should be 32k
[13:42] <ppisati> right
[13:43] <ppisati> but then it says ".. OR CONFIG_DEFAULT_MMAP_MIN_ADDR = 64k" without enforcing it to be !arm
[13:43] <smb> ah
[13:44] <ppisati> or at least that's how i read it... let me try.. :)
[13:48] <tgardner> ppisati, are you gonna respin the config patches to include the enforcer fixes ?
[13:48] <ppisati> tgardner: will do
[13:49] <tgardner> ppisati, thanks
[13:52]  * tgardner bounces tangerine for kernel update
[14:20]  * smb loves those admins taking systems down without warning...
[14:21] <tgardner> smb, perhaps we should start scheduling regular maintenance
[14:22] <tgardner> you're right though, I should have checked to see if you were actually doing something.
[14:22] <smb> Lickily the compile was through before
[14:22] <smb> But a "wall" would be nice :)
[14:22] <tgardner> well, I did check that there were no jobs running
[14:23] <tgardner> whats a "wall" ?
[14:23] <smb> Used to be message to all users...
[14:23] <smb> Hm, not sure its still there
[14:23] <tgardner> sure is, huh.
[14:25] <tgardner> smb, I  guess that would work as long as you weren't running some program that refreshed the screen all the time, like less or top
[14:25] <smb> tgardner, Right, that would just give a little more warning. Sadly being in the middle of a compile also makes it less usefull... 
[14:26] <tgardner> smb, but since I check for that....
[14:27] <smb> True. Hm maintenance windows probably would work too. Though I fear, I'll be the one to forget when they are...
[14:28] <smb> doubly so being in a bisect that drives one nuts...
[14:37] <smb> tgardner, Are you doing larger maintenance on gomeisa?
[14:37]  * tgardner hates it when you reboot a server and it doesn't come back
[14:38] <smb> ah
[14:38]  * smb crawls back under his rock
[14:38] <tgardner> smb, gimme a bit...
[15:26]  * ogasawara back in 20
[15:49] <aquarius> I've just tried to report a suspend bug with "ubuntu-bug linux", but apport claims I'm not running an Ubuntu package; I'm running precise, installed from yesterday's nightly build and upgraded today. What might I be doing wrong?
[15:50] <aquarius> (or, as a different question: how should I report bugs?)
[16:02] <jsalisbury> **
[16:02] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[16:02] <jsalisbury> **
[17:24] <arges> apw, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/833300  <-- this is the bug I'm talking about. wondering if its similar. essentially with a patch that is upstreamed with can read files with permission 111, but can't execute them. right now the upstream guy says its most likely a client issue. 
[17:24] <ubot2> Launchpad bug 833300 in linux "NFSv4 mount point does not allow binary files to run when permissions are set only to execute" [Medium,In progress]
[17:27] <brendand> for those in the meeting earlier, the document is now editable
[17:27] <brendand> it has a comments field
[17:27] <brendand> https://docs.google.com/spreadsheet/ccc?key=0AphFraZYTghddElqTHl3NmZsWXVDYkMxcE5zX3EtR0E
[17:27] <bjf> ls
[17:31] <ogasawara> brendand: what's the difference between "Docking station/Docking Station" and "Docking station/Generic Docking Station"
[17:37] <brendand> ogasawara - you can definitely ignore those, we don't test docking stations or anything that is not part of the system itself. as to why they are categorised differently, jedimike might be able to explain
[17:38] <brendand> jedimike - ogasawara is asking where the categories come from?
[17:39] <jedimike> they are the ones that pci and usb devices fit in to, for example, the ones reported by lspci
[17:39] <brendand> jedimike - they're taken directly from lspci?
[17:40] <jedimike> so a docking station most likely wouldn't show us in the pci or usb device list and get reported as a device
[17:40] <jedimike> brendand, ogasawara they're taken from pci.ids and usb.ids
[17:48] <brendand> it's probably safe to say Generic system peripheral/SD Host controller should be in, right?
[18:59]  * tgardner -> lunch
[19:27] <SpamapS> hey, I'm getting ready to copy the kernel into oneiric-proposed .. please remind me for the 14th time which source packages other than 'linux' and 'linux-meta' I need to copy.
[19:29] <bjf> SpamapS: that should be good enough for now
[19:35] <SpamapS> Ok, they should be copied now
[19:36] <SpamapS> hrm, doesn't show yet
[19:52] <herton> SpamapS, also linux-backports-modules-3.0.0
[19:54] <SpamapS> herton: done
[19:54] <herton> thanks
[20:08] <bjf> herton, thanks for that
[21:05] <cyphermox> apw: I have a small patch that fixes propagating net.ipv6.conf.all.use_tempaddr to the undrlying interfaces; just need to clean it up a bit/fix one smaller issue I noticed, and I'll send it for a quick review by the team before I send it to netdev.
[21:05] <apw> cyphermox, sounds good to me
[21:07] <cyphermox> it was surprisingly simple to do; I was scared to see lots of black magic in kernel code.
[21:24]  * tgardner -> EOD
[22:39] <sforshee> cnd, you have a macbook, don't you?
[22:40] <cnd> sforshee, yeah
[22:40] <cnd> macbook 5,1
[22:40] <sforshee> do you know if there's a way under linux to enable the click and drag like under mac os?
[22:40] <sforshee> where you depress the clickpad with one finger and drag with another
[22:42] <sforshee> cnd, ^
[22:42] <cnd> sforshee, yes and no, we are going to work on it this cycle
[22:43] <sforshee> cnd, so currently, is the answer no?
[22:43] <cnd> sforshee, otp, let me get back to you
[22:43] <sforshee> cnd, np
[23:43] <cnd> sforshee, sorry, long meeting
[23:43] <cnd> so the only way to get similar functionality right now is to mask out a portion of the touchpad at the bottom
[23:43] <cnd> so that any touches there are ignored, and you can click with impunity :)
[23:45] <cnd> the size of the area is determined by the Synaptics Area setting
[23:45] <cnd> you can see an example config in /usr/share/X11/xorg.conf.d/51-synaptics-quirks.conf
[23:45] <cnd> in the conf file it has a different name "AreaBottomEdge"
[23:56] <vanhoof> cnd: been meaning to play w/ that, what's a good starting place for a magic trackpad AreaBottomEdge wise
[23:59] <cnd> ok