[00:10] <TheMuso> Woohoo! There is a new release of the l4t stack, and we now have a gstreamer module for multimedia playback, and they even included a player with it.
[00:19] <twb> lilstevie: can you think of any reason why wifi wpa wouldn't work out-of-the-box under the ubuntu installed from your olife thingo?
[00:20] <twb> I noticed that android uses a different MAC for the same wlan0 NIC, so I have enabled both on the AP (openwrt hostapd), but it still doesn't like me.
[00:21] <twb> http://paste.debian.net/148936/ is the approach I'm trying
[00:23] <TheMuso> twb: Which kernel are you running?
[00:25] <twb> 2.6.36.4
[00:25] <twb> The guy next to me has the 16GB model and is running olife as well and his is working.
[00:25] <twb> And I double-checked the PSK so WTF
[00:25] <TheMuso> Ah ok. I had to try a couple of times to connect to my WPA network, but it connected eventually.
[00:25] <TheMuso> But I use 2.6.38 with uBoot.
[00:26] <TheMuso> Sorry I should clarrify. I can connect without issue running under 2.6.38, but had a few times where I had to retry when using the 2.6.36 kernel.
[00:26] <twb> OK
[00:29] <twb> Grr
[00:29] <twb> I can see wpa_supplicant associating and then being kicked off again (reason=0)
[00:31] <doko> infinity, the gcc-snapshot build on ain could be killed (superseded and will fail anyway). new one running on satiniash. could need a panda to build. afk now
[00:59] <twb> OK I give up for now
[01:00] <twb> Same AP is working under android, even.  Even *copying* the wpa_supplicant.conf from android doesn't work.
[01:27] <lilstevie> twb: interesting
[01:28] <lilstevie> twb: can you pastie your whole dmesg
[01:28] <lilstevie> TheMuso: yeah, u-boot installs are cool :p
[01:29] <lilstevie> twb: wait, if you are using wpa_supplicant rather than network manager I have a few suggestions
[01:34] <steev_> lilstevie: NM uses wpa_supplicant
[01:35] <Sycro5> Hello, I'm looking for some help regarding bluetooth on the Pandaboard.  I've tried to use both the onboard BT as well as an external USB BT adapter without success.  I'm running Ubuntu 11.10.  Has anyone successful got BT working or have suggestions for me?
[01:37] <Sycro5> with the onboard bluetooth, I'm not even able to turn BT on.  When I use the adapter, I can turn it on and even find BT devices but can't pair with any of them
[01:40] <lilstevie> steev_: yes, but using the supplicant directly isn't straight forward
[01:44] <Sycro5> So would it be possible to pair a wii remote with the pandaboard to use the wii remotes IR camera?
[01:44] <Sycro5> And is it easier to use the onboard BT or the USB dongle?
[02:01] <twb> lilstevie: FWIW using supplicant directly is the same process I'm doing on every other wifi client I have
[02:01] <twb> lilstevie: those instructions I posted?   I wrote those :-)
[02:01] <twb> Which dmesg did you want?
[02:02] <lilstevie> your booted one, but then I saw how you were doing it
[02:02] <twb> k
[02:02] <lilstevie> http://rootzwiki.com/topic/947-ubuntu-on-the-transformer/page__view__findpost__p__23297
[02:03] <lilstevie> thats how it was done before nm accepted the device as wireless
[02:04] <twb> I could try nm if you like
[02:05] <twb> I didn't try ap_scan=2; I'm getting as far as associating and auth'ing w/the AP, so that shouldn't matter...
[02:05] <lilstevie> fair enought
[02:05] <lilstevie> eough even
[02:05] <lilstevie> ah
[02:05] <lilstevie> I give up
[02:06] <twb> Yeah, it's bloody weird
[02:06] <twb> I'm going to test at home before I fiddle around much more, because at home I have a single PSK for all MACs, whereas as at work each MAC has its own PSK
[02:06] <twb> (Yes, I gave the same PSK to both android and ubuntu MACs)
[02:08] <lilstevie> yeah, the MAC issue is a bit of a pita
[02:09] <lilstevie> a closed source, and libbionic daemon does that
[02:10] <twb> Hum, maybe I have accdentally stoppd that
[02:11] <twb> IIRC the only service I turned off was lightdm tho
[02:15] <lilstevie> lol
[02:16] <lilstevie> I mean the MAC issue is a pita because it won't run
[02:16] <twb> Ah right
[02:16] <lilstevie> and is closed source
[02:48] <Sycro5> can anyone help me out with the bluetooth issue?
=== 77CAAC43S is now known as alf_
[12:24] <q4a> hi all. Is there fix or workaround of this bug? https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/901847
[12:24] <ubot2> Launchpad bug 901847 in ubiquity "armhf+omap4 desktop installer dies in plugininstall.py" [High,Confirmed]
[12:25] <ogra_> not yet, no
[12:25] <q4a> thx for answer
[12:28] <doko> janimo, ping on bug 861296, linux-ac100
[12:28] <ubot2> Launchpad bug 861296 in linux-ti-omap4 "mmap fails to allocate 2030Mb heap on ARM" [Undecided,Fix committed] https://launchpad.net/bugs/861296
[12:37] <ogra_> bah, someone was faster on giving back gst-plugins-good
[12:37]  * ogra_ bets infinity ...
[12:37] <lool> Gave back gst-plugins-good0.10/armel (and /powerpc) against latest libavc1394 to pick up multiarch .la file change
[12:38] <lool> ogra_: I was  :-0
[12:38] <ogra_> haha
[12:38] <lool> it took me a bit long to figure out that the .la file had been fixed already
[14:27] <janimo> doko, yes? Regarding the mmap bug?
[14:42] <doko> janimo, yes, apply to linux-ac100
[14:43] <janimo> doko, will for precise, I am not sure it's worth the hassle for oneiric
[14:44] <janimo> only for consistency maybe
[14:45] <doko> janimo: please do it for consistency then.
[14:47] <ogra_> janimo, while youre at it you could also do the config change :)
[14:47] <ogra_> so that the internal mic works
[15:04] <janimo> ogra_, which change is that? I was not aware we're only one config toggle away from mic working
[15:04] <ogra_> just that one :)
[15:05] <ogra_> (usb sound stuff)
=== brendand_ is now known as brendand
[16:37] <ogra_> lool, poke
[16:38] <ogra_> lool, david pointed me to you, we seem to have some weird armhf behavior in bug 901847
[16:38] <ubot2> Launchpad bug 901847 in ubiquity "armhf+omap4 desktop installer dies in plugininstall.py" [High,Confirmed] https://launchpad.net/bugs/901847
[16:38] <ogra_> seems users cant execute shells in hf installs
[16:40] <lool> ogra_: Do you have such an environment?
[16:40] <lool> I would suspect it could be due to the runtime linker
[16:40] <ogra_> i only have the chroot i mentioned... where it apparently works ...
[16:40] <ogra_> but xranby has an install on his ac100
[16:40] <lool> xranby: Oy
[16:41] <ogra_> (the bug manifests the same way on all hf images it seems)
=== Ursinha is now known as Ursinha-lunch
[16:45] <lool> other chroot calls work, so probably something with sudo / pam
[16:46] <lool> I wonder whether this is relevant: Dec  8 19:55:41 localhost ubiquity: dpkg-trigger: error: must be called from a maintainer script (or with a --by-package option)
[16:46] <infinity> lool: No, that's a red herring.
=== prpplague^2 is now known as prpplague
[16:46] <infinity> I wonder if this relates to the procps "when I upgrade, my system explodes" madness somehow.
[16:47] <infinity> Cause users can definitely execute shells on armhf.  If they couldn't, our buildds wouldn't work.
[16:47] <ogra_> but thats not a chroot ... (the breakage i mean)
[16:47] <infinity> ogra_: What do chroots have to do with anything?
[16:47] <ogra_> well, in chroots it works ...
[16:48] <ogra_> i can chroot/sudo into a user shell
[16:48] <ogra_> while the same thing doesnt work on a bare install
[16:48] <GrueMaster> To add to that, I have a semi-working netinstall (prior to the libc6 udeb issue) that will only log me in if I have init=/bin/sh.
[16:48] <ogra_> root can run any shell on that same install though
[16:48] <infinity> ogra_: Sure, but I still suspect it's the same issue.
[16:49] <ogra_> hmm
[16:49] <GrueMaster> I can't log in to the same image with a normal init, even with ssh.  Gets most of the way in, but chokes on giving me a shell prompt.
[16:49] <infinity> Boom, killed.
[16:49] <ogra_> try systemd instead :P
[16:49] <infinity> Just like that.
[16:49] <infinity> ogra_: /etc/init.d/procps start
[16:50] <infinity> ogra_: Do that in a chroot with proc mounted, watch system explode for all !root users.
[16:50] <infinity> ogra_: Now, realise that any installed system does that on boot.
[16:50] <infinity> GrueMaster: Remove procps's init script and see if it boots.
[16:50] <ogra_> infinity, hmm, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631807 ??
[16:50] <ubot2> Debian bug 631807 in libcap-ng0 "segfault in libcap-ng0 is back on armel - filecap , bluetoothd etc" [Important,Open]
[16:51] <GrueMaster> ok.  Will try (if the system is still imaged).
[16:51] <ogra_> i wonder if that could reach into our issue
[16:52] <infinity> Maybe.
[16:52] <infinity> But I don't see a SEGV here.
[16:52] <ogra_> yeah
[16:53] <infinity> GrueMaster: (note that it's actually an upstart job, so /etc/init/procps.conf is what needs to go)
[16:54] <GrueMaster> I know.
[16:54] <infinity> So, something in "cat /etc/sysctl.d/*.conf /etc/sysctl.conf | sysctl -e -p -" is killing us.
[16:54] <infinity> Just need to iterate through reboots until I find the culprit.
[16:54] <ogra_> does it die if you run it manually ?
[16:54] <infinity> I can reboot and see.
[16:55] <GrueMaster> bah.  System was reimaged to precise armel.  I don't have that install to test (and netinst is borked due to libc6-udeb).
[16:56] <GrueMaster> Will muck with a server image.
[16:56] <infinity> Server dies in the installer with the same issue.
[16:58] <infinity> ogra_: Yeah, doing it manually produces the same result.  Which is comforting.  It's not upstart's fault.
[16:58] <infinity> ogra_: Just one of these settings is broken.
[16:58] <ogra_> yay
[16:59]  * infinity is inclined to blame one of:
[16:59] <infinity> kernel.yama.ptrace_scope = 1
[16:59] <infinity> vm.mmap_min_addr = 65536
[16:59] <ogra_> and since its on panda as well, it cant be my tewaks in the ac100
[16:59] <infinity> Another reboot and testing.
[16:59] <ogra_> hmm, the min addr thing was required for something on armel
[16:59]  * ogra_ forgot what though
[17:00] <infinity> Wait, does the file installed on armel differ?
[17:00] <ogra_> no
[17:00] <ogra_> same file
[17:00] <ogra_> but apparently different behavior
[17:00] <infinity> No, it's a different value.
[17:00] <infinity> At least, it is here...
[17:00] <ogra_> cant
[17:00] <infinity> Why can't it be? :P
[17:01] <ogra_> the bit putting it there is the same on both
[17:01] <ogra_> cat attack, cant type atm ...
[17:02] <infinity> Well, the default is:
[17:02] <infinity> vm.mmap_min_addr = 65536
[17:02] <infinity> My quickstart has:
[17:02] <ogra_> right
[17:02] <infinity> # ARM-specific default:
[17:02] <infinity> vm.mmap_min_addr = 32768
[17:02] <ogra_> ugh
[17:02] <ogra_> how does that get there
[17:03] <ogra_> jasper puts it in place on non ac100
[17:03] <infinity> Eh?
[17:03] <infinity> It does no such thing.
[17:03] <ogra_> and ac100-tarball-installer in ac100
[17:03] <infinity> adconrad@cthulhu:~/pps/jasper-initramfs-0.66$ rgrep zeropage *
[17:03] <infinity> adconrad@cthulhu:~/pps/jasper-initramfs-0.66$
[17:03] <infinity> You may be mistaken.
[17:03] <ogra_> jasper_setup should
[17:03] <GrueMaster> Interesting on the mmap_min_addr thing.  On omap kernel, that is the correct value, but on omap4 it is 32768
[17:04] <GrueMaster> Makes kernel SRU testing fail btw.
[17:05] <infinity> For the record, this fixes it:
[17:05] <infinity> sed -i -e 's/65536/32768/' /etc/sysctl.d/10-zeropage.conf
[17:06] <infinity> So, we should probably just ship the right value in procps.
[17:06] <ogra_> yep
[17:06] <infinity> Cause editing conffiles from other packages is wrong, wrong, wrong.
[17:06] <ogra_> jasper never did that
[17:06] <infinity> But what did?
[17:06] <ogra_> its a .d dir
[17:06] <infinity> Something gave me the right value on my QS.
[17:07] <infinity> And even with a comment!
[17:07] <ogra_> jasper puts an override file in place
[17:07] <infinity> ogra_: Yes, but this is the same file.
[17:07] <infinity> ogra_: Same filename as the one in procps.
[17:07] <ogra_> strange
[17:07] <infinity> Anyhow, now that I've found the issue, will fix after my call.
[17:07] <ogra_> awesome
[17:17] <ogra_> infinity, oh, i was wrong anyway wrt jasper ... vm.min_free_kbytes = 8192 is what we set there (for an USB NIC issue)
[17:18] <ogra_> workaround for bug 746137
[17:18] <ubot2> Launchpad bug 746137 in jasper-initramfs "Page allocation failure on Pandaboard and Beagle XM" [Undecided,Fix released] https://launchpad.net/bugs/746137
[17:18] <ogra_> see sysctl/30-jasper-smsc-min-free-kbytes.conf
[17:19] <ogra_> in the jasper tree
[17:28] <ogra_>         # If a non-arch-specific default exists, install the arch-specific
[17:28] <ogra_>         # version of the conf in place of it, otherwise, build up a general
[17:28] <ogra_>         # 10-arch-specific.conf file.
[17:28] <ogra_>         for archconf in debian/sysctl.d/*.conf.$(DEB_HOST_ARCH); do \
[17:28] <ogra_> infinity, ... nothing modifies it, procps itself puts a different file in place for armel
[17:28] <ogra_> (thats from debian/rules ... i think we just need to drop the armel file from the source)
[17:29] <ogra_> err, other way round, cp the armel file to an armhf file
[17:30]  * ogra_ does that 
[17:34] <ogra_> uploaded
[17:34] <infinity> ogra_: \o/
[17:38] <lool> Was this the sudo chroot issue?
[17:38] <ogra_> lool, right
[17:38] <ogra_> vm.mmap_min_addr being set to a too high value
[17:39] <ogra_> since the original fix was bound to the armel arch naming
[17:40] <lool> Ok; I'll stop the install I was running -- it's really painful to work with full images instead of a small armhf chroot!
[17:41] <ogra_> just use ubuntu-core if you need a minimal one :)
[17:42] <ogra_> (just take an existing install and replace the rootfs with ubuntu-core and add a root pw)
[18:10] <infinity> ogra_: I do wonder how many other armel-specific hacks we might be missing for armhf. :/
[18:10] <ogra_> well, iirc there were a few made by the security team like this one
[18:10] <ogra_> but they were rather kernel defaults so we should be good here
[18:11] <ogra_> i guess we'll run into them over time
[18:11] <ogra_> the bad thing is that i really cant remember all of them anymore ... i only remembered the procps thing that kees did when i actually looked at the code
[18:12] <ogra_> the bad part here is that it wasnt even mentioned in the changelog or anything
=== Jack87 is now known as Jack87|Away
[18:42] <ogra_> infinity, hmm, i was hoping the janitor just had a hiccup
[18:42] <ogra_> (thats why i didnt manually close yet)
[18:42] <infinity> ogra_: I didn't check timing, but I assume you uploaded before you added the procps task.
[18:43] <ogra_> yeah, in the hope it just closes by bug number :P
[18:43] <infinity> Yeah, it won't. ;)
[18:43] <ogra_> which it apparently doesnt anymore
[18:43] <infinity> A procps upload can only close a bug in procps.
[18:43] <ogra_> well, it used to not care for the package in the past
[18:44] <infinity> (Which I think is a silly limitation that creates busywork, but whatever)
[18:44] <ogra_> right
[18:46] <GrueMaster> We should still make sure the kernels have the correct  CONFIG_LSM_MMAP_MIN_ADDR setting.  Currently, they are different on omap vs omap4.
[18:46] <infinity> GrueMaster: Except that, on boot, they all get set to the procps-provided one anyway.
[18:46] <ogra_> doesnt matter since procps overrides them (on all arches) anyway
[18:46] <infinity> (But yes, the kernel defaults should match)
[18:46] <ogra_> *snap*
[18:46] <ogra_> agreed
[18:47] <infinity> GrueMaster: Which one's wrong?
[18:47] <ogra_> and there are plenty of packages that modify them as well
[18:47] <infinity> Oh, I'm betting omap, because it probably matches the x86 kernels.
[18:47] <infinity> Right?
[18:47] <ogra_> via sysctl.d files
[18:47] <GrueMaster> Well, the QRT scripts look at the kernel config settings.
[18:47] <ogra_> which is completely wrong in this case
[18:47] <GrueMaster> Not sure, but I would assume the omap4, since it is out-of-main.
[18:48] <GrueMaster> What should be correct, 32768 or 65536?
[18:48] <infinity> 32768
[18:48] <GrueMaster> Ok, them omap is wrong.  At least in the kernel config.
[18:48] <ogra_> fun
[18:48] <infinity> Though, that's questionable.  I wish I could track down WHY arm was set differently.
[18:49] <infinity> ogra_: Any ideas there?
[18:49] <ogra_> i dont remember it anymore
[18:49] <ogra_> i was involved in it
[18:49] <infinity> Awesome.
[18:49] <ogra_> we should ask kees
[18:49] <ogra_> he probably remembers it better than me
[18:49] <GrueMaster> He didn't know.
[18:49] <ogra_> it dates back to jaunty
[18:49] <infinity> GrueMaster: For now, then, making omap match the rest sounds "correct", until we can sort out why not.
[18:49] <GrueMaster> I worked with him all day Friday on these scripts.
[18:51] <ogra_> iirc it blocks a security feature of the kernel on arm if it is set to high
[18:51] <ogra_> null pointer dereference or some such
[18:52] <infinity> That's what it's for in the first place (preventing null dereferencing)
[18:52] <kees> hola
[18:52] <infinity> But I'm willing to believe it's weird on ARM.  We should just get the omap default fixed.
[18:52] <GrueMaster> Well, none of the scripts are broken now.  I worked with him Friday, and we have everything running on all arm HW.
[18:52] <infinity> kees: Yo.
[18:53] <kees> mmap_min_addr on arm needed to be 32k because, IIRC, qemu and some of the dynamic loaders put stuff below 64k.
[18:53] <infinity> kees: Wouldn't that be true on all arches...?
[18:53] <kees> infinity: all arch flavors? yes, I assumed so.
[18:54] <infinity> kees: No, I meant !arm... Curious why qemu would be different only there.
[18:54] <kees> I have no problem seeing it raised, btw. this was a requirement from ogra_ originally.
[18:54] <ogra_> yay
[18:54] <ogra_> it was the dynamic loader thing
[18:54] <ogra_> now i remember
[18:54] <infinity> Raising it seems to make the system explode, so I suspect we were right. :P
[18:54] <kees> infinity: oh, I assume because memory layouts were different between archs
[18:54] <infinity> I just wish the reasoning had been documented.
[18:55] <ogra_> infinity, qemu even explodes with values above 4k iirc
[18:55] <ogra_> and wine or dosemu have other values as well
[18:55] <kees> oh! that's right, qemu was 4k, hence a sysctl file on install. yeah
[18:55]  * infinity nods.
[18:55] <infinity> Alright.
[18:55] <ogra_> and there might be other packages i dont re,ember
[18:55] <infinity> So, ARM's ld.so is weird or something.  Having been in there, I can buy that.
[18:55] <kees> dosemu is fully emulated so it doesn't care about mmap_min_addr. wine in 32bit mode doesn't care either. wine in 16bit mode beens access to 0 addr.
[18:56] <ogra_> ah, right
[18:56] <kees> beens? needs.
[18:56] <infinity> beens!
[18:56] <ogra_> heh
[18:56] <kees> what an odd typo
[18:56] <infinity> kees: You're an odd fellow.
[18:56] <infinity> kees: Sees to fit.
[18:56] <kees> infinity: fair point
[18:56] <infinity> Seems, too.
[18:56] <infinity> Fuck typing.
[18:56] <kees> infinity: where would you have expected the 32k thing to be documented, btw?
[18:57]  * ogra_ wants a t-shirt with that
[18:57] <infinity> kees: In the sysctl fragment that's different on ARM, perhaps?
[18:57] <ogra_> kees, iirc there was a bug for it
[18:57] <ogra_> but launchpad doesnt like to find it
[18:57] <infinity> kees: Right now, it has a very unhelpful "# ARM-secific default:" comment.
[18:57] <ogra_> for the arm part at lest
[18:57] <kees> infinity: ah, yeah
[18:57] <ogra_> i find all the wine bugs though
[18:58] <kees> # ARM-specific default, due to the dynamic loader using regions below 64k:
[18:58] <kees> ^^ how about that?
[18:58] <ogra_> and i know we discussed it at lenght back then
[18:58] <ogra_> so there *must* be irc logs
[18:58] <ogra_> but i cant find them either
[18:58] <infinity> kees: If that's the truth, then yes, sounds lovely. ;)
[18:59] <infinity> kees: If by "the dynamic loader", you mean "ld.so", being specific doesn't hurt.
[18:59] <kees> ogra_: how should that comment read? was there a bug for it?
[19:00] <GrueMaster> I just did a google for arm sysctl mmap_min_addr site:launchpad.net and all the results point to qemu.
[19:00] <GrueMaster> Karmic timeframe.
[19:00] <ogra_> kees, i *think* we had a bug ... but seriously, that was jaunty or karmic my mind doesnt date back that far
[19:00] <kees> yeah, me either
[19:01] <ogra_> i remember discussing the qemu part with you in dublin
[19:01] <kees> yeah, that was a whole different issue. that was the 4k part, not the 32k
[19:01] <ogra_> but at that time the procps side was already in place
[19:01] <ogra_> and we did that one online
[19:01] <ogra_> its weird that google doesnt find a single irc log
[19:02] <ogra_> http://irclogs.ubuntu.com/2009/03/18/%23ubuntu-kernel.txt
[19:02] <ogra_> ha !
[19:03] <ogra_> doesnt have the explanatiojn though :(
[19:03] <ogra_> only the discussion
[19:03] <kees> yeah
[19:03] <ogra_> [17:38] <ogra> the help of SECURITY_DEFAULT_MMAP_MIN_ADDR says "On arm and other archs it should not be higher than 32768."
[19:03] <ogra_> thats the reason :)
[19:04] <ogra_> we did it because i read docs :P
[19:04] <infinity> [17:29] <kees> according to the Kconfig help text, anyway
[19:04] <infinity> [17:29] <kees> ia64, ppc64, x86: 65536, all others: 32768
[19:04] <ogra_> yep
[19:05] <infinity> Alright, well.  Fixed now.  I have eglibc things to do.
[19:05] <GrueMaster> So we need to fix omap.  Good to know.
[19:05] <infinity> GrueMaster: Want to file a bug?
[19:05] <GrueMaster> yep.  I like filing kernel bugs.  Keeps them on their toes.
[19:06] <infinity> Thankfully, init/procps probably starts early enough for it to be a non-issue, but...
[19:16] <GrueMaster> Other than kconfig saying we should set it this way, is there any other compelling reason?
[19:16] <parin1> on ubuntu 11.10 touchscreen freezes after some time
[19:17] <parin1> i use http://www.amazon.com/e2239Fwt-21-5-LED-Touchscreen-Monitor/dp/B0056J9JPC
[19:18] <slangasek> infinity, kees, ogra_: current qemu does not need any special handling of minimum memory addresses; we killed that sysctl file off a while ago
[19:18] <kees> slangasek: cool
[19:19] <infinity> GrueMaster: Well, Kconfig seems to be right. ;)
[19:20] <GrueMaster> I'm just curious as to what it would affect.  It has been 65536 on omap since we started using main (natty or oneiric - can't remember).
[19:21] <infinity> GrueMaster: Except that it's reset on boot.
[19:21] <infinity> GrueMaster: So, it's not actually that at all.
[19:21] <infinity> GrueMaster: if it wasn't for the procps init job setting it to 32k, everything non-root would fail.
[19:21] <infinity> GrueMaster: (As seen by the current armhf bug that Oli just fixed)
[19:22] <GrueMaster> Ah.
[19:22] <GrueMaster> ok.
[19:23] <GrueMaster> So this may impact booting w/o initrd possibly?
[19:23] <infinity> Nah.
[19:23]  * GrueMaster needs to see how far back this affects omap kernels.
[19:24] <infinity> But it impacts anything that one might try to start from init as !root before the procps job runs.
[19:24] <infinity> (Which, in practice, seems to be little or nothing, but still)
[19:24] <infinity> A kernel default that doesn't allow non-root use seems suboptimal. ;)
[19:26] <GrueMaster> I'm just wondering if it needs attention for the next SRU run.
[19:27] <infinity> It should probably be fixed in omap SRU kernels.  Can't hurt to fix it.
[19:27] <infinity> But it's not particularly critical, if things have been working.
[19:27] <slangasek> infinity: why does this affect !root?  Does this imply qemu should in fact re-add the sysctl file, even though I haven't been able to find any failures with it gone?
[19:28] <GrueMaster> Ok, so I need to backtrack and see how far back it is affected.  I'll put a med priority on it.
[19:29] <infinity> slangasek: The setting only affects !root.  Root can map whatever they want.
[19:29] <slangasek> yes, and when I run qemu, I run !root
[19:29] <infinity> slangasek: In the ARM case, having the wrong setting (64k) breaks.
[19:29] <infinity> slangasek: The qemu thing is entirely unrelated.
[19:29] <slangasek> ok
[19:37] <parin1> any one used touchscreen on ubuntu 11.10?
[19:46] <GrueMaster> infinity: ogra_  Bug #903346 filed.  Will list broken kernel releases that need to be addressed shortly.
[19:46] <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
[19:55] <ogra_> GrueMaster, awesome, great
[19:56] <GrueMaster> Confirmed also in Natty.  Pulling maverick to see if it is affected as well.
[19:56] <ogra_> funny that omap still works though
[19:56] <ogra_> why are you able to exec anything if its 65k
[19:57] <infinity> ogra_: Because procps resets it.
[19:57]  * GrueMaster sheepishly admits to accidentally purging release images on desktop before checking internal mirror to verify backup).
[19:57] <GrueMaster> The sysctl is there to correct it.
[19:57] <ogra_> then we have been really really lucky with our initrd and upstart
[19:57] <infinity> ogra_: The initrd runs entirely as root.
[19:57] <ogra_> oh, indeed
[19:57] <infinity> ogra_: As do most/all upstart jobs before the procps script.
[19:57] <ogra_> and pid 0 as well
[19:58] <ogra_> you mentioned it before, now i understand what you meant :P
[19:58]  * ogra_ didnt relate that comment to omap before
[19:59] <infinity> Right.  I need a short nap to recover from last night before I finish this eglibc merge.
[19:59] <GrueMaster> So this really only would affect users that take our code and do weird embedded work with it (or other things).
[19:59] <infinity> I suspect it's best not to upload libc when I'm in this state. :P
[19:59] <ogra_> nobody doing embedded work would use our stff anyway
[19:59] <ogra_> infinity, go to bed
[19:59]  * ogra_ goes back to TV
[20:00]  * GrueMaster considers searching for lunch.
[20:00] <infinity> GrueMaster: Or someone naively removing the config file, or disabling the procps init, or trying to run an init job as !root before procps's runs, or...
[20:01] <infinity> GrueMaster: In the end, the procps bits and the kernel defaults should match, it's pretty unexpectedly strange when they don't, I'd say.
[20:01] <ogra_> if i *would* do embedded work with ubuntu i would do it as initrd hooks and abuse update-initramfs to build my rootfses though
[20:01] <infinity> (Especially since the sysctl snippets claim to mirror the defaults)
[20:01] <ogra_> to keep it as tiny as possible
[20:02] <ogra_> and i bet others doing embedded stuf would do something similar ... anyway i would expect most stuff to run as root in embedded
[20:02] <ogra_> anyway, really TV now
=== Ursinha-lunch is now known as Ursinha