[00:00] <satellit> mjrosenb: http://support.google.com/chromeos/bin/answer.py?hl=en&answer=1080595   how to recover chromebook
[00:02] <mjrosenb> satellit: as I said earlier, I can recover it
[00:02] <mjrosenb> also, I suspect that won't work on my laptop
[07:55] <dholbach> good morning
[08:24] <mjrosenb> morning.
[08:24] <mjrosenb> http://pastebin.mozilla.org/2001455
[08:24] <mjrosenb> that is from my pandaboard, I just tried to upgrade a fresh install to 12.10, and got a black screen.
[08:25] <mjrosenb> I also got this in dmesg
[08:25] <mjrosenb> [    7.703308] init: Failed to spawn hybrid-gfx main process: unable to execute: No such file or directory
[08:31] <mjrosenb> ok, I have the sd card plugged into my laptop, and I want to enable the ssh server... is there an easy way to do this?
[09:01] <infinity> mjrosenb: You're missing libdrm-omap1, looks like.
[09:02] <infinity> mjrosenb: Also, it's not so much "enabling" the ssh server as installing the package, which you'd need to do either on an ARM machine, or with emulation.
[09:02] <mjrosenb> qemu-system-arm does not have an omap4 option from what i can tell
[09:03] <mjrosenb> i'm actually kind of surprised there isn't a pandaboard option
[09:03] <infinity> I'm not.
[09:04] <infinity> Emulating a Panda isn't something qemu upstream would care to do, and TI didn't see the value in writing a board-specific emulator (most vendors don't)
[09:04] <infinity> Anyhow, I didn't mean full system emulation.
[09:04] <infinity> qemu-user-static would be fine.
[09:05] <infinity> Mount your SD card to somewhere (we'll say /mnt), apt-get install qemu-user-static && cp /usr/bin/qemu-arm-static /mnt/usr/bin && chroot /mnt su -
[09:06] <infinity> Presto, you're in your ARM system as a chroot.
[09:06] <infinity> apt-get install ssh libdrm-omap1
[09:07] <infinity> apt-get install pvr-omap4 # if you wanted some non-free 3D action.
[09:08] <infinity> Which is probably necessary, if you're running Ubuntu/Unity.
[09:11] <mjrosenb> for whatever reason, ssh seems to already be installed
[09:11] <mjrosenb> but it isn't starting
[09:11] <mjrosenb> and it isn't bringing up the network
[10:10] <hrw> infinity: can you share /var/log/Xorg.0.log from panda with opengles support?
[10:12] <infinity> mjrosenb: If your network is wireless-only, that could explain it.
[10:12] <infinity> hrw: My Panda has no X right now.
[10:14] <mjrosenb> infinity: nope, eth0 is the pandaboard's onboard connection
[10:15] <infinity> mjrosenb: Oh, curious.  Maybe it hates you/
[10:16] <hrw> infinity: ok
[11:25] <mjrosenb> sweet, I can ssh into my pandaboard again
[12:26] <mjrosenb> ok, I know I did this on my last install; what do I need to run in order to get a non-hf library installed?
[12:27] <mjrosenb> or better yet, what on earth is it called?
[12:27] <mjrosenb> i'm searching for multilib
[12:27] <mjrosenb> but that is giving man irrelevant results
[12:45] <infinity> mjrosenb: Depends on which non-hf library you need.
[12:46] <infinity> mjrosenb: If it's just libc6 (and a gcc that can build sf binaries), there are multilib versions.
[12:46] <mjrosenb> looks like the answer was
[12:46] <mjrosenb> dpkg --add-architecture armel
[12:46] <mjrosenb> which is surprisingly hard to find via google
[12:46] <infinity> mjrosenb: If it's more comprehensive, you want multiarch (dpkg --add-architecture armel && apt-get update && apt-get install libfoo1:armel)
[12:47] <infinity> That said, I wouldn't rely on armhf/armel multiarch going forward, since we've dropped armel in raring...
[12:47] <infinity> What are you doing that *needs* soft-float libraries?
[12:47] <mjrosenb> y'all are making my life really hard, you know that?
[12:48] <mjrosenb> i'm testing fennec, which is supposed to run on android which is armel.
[12:48] <infinity> .. unless it's newer Android, then it's not. :P
[12:49] <mjrosenb> how does that work from a packages' point of view?
[12:49] <infinity> That said, fennec could be rebuilt...
[12:49] <mjrosenb> do they need to upload two .apks, one for armel, one for armhf?
[12:49] <infinity> I have no idea how Android is handling the sf/hf transition.
[12:50] <infinity> Then again, most apps aren't C binaries, so the point is moot for them.
[12:50] <mjrosenb> you know what version they made the transition in?
[12:50] <infinity> It could also be that this is all a bit different with bionic, I have no idea.
[12:51] <infinity> I just know they were doing the transition (or maybe had done so).
[12:51] <sveinse> Does anyone know if Network Manager regularely scans for a list of available networks in precise? We're having some problems with communication locking up for 2-3 seconds and wondering if this could be related to nm scanning the networks
[12:51] <infinity> mjrosenb: It's possible they haven't actually made the switch yet for bionic-based systems (ie: Android), though they definitely did for ChromeOS.
[12:52] <infinity> Confusing world.
[12:52] <infinity> mjrosenb: Still, for an open-source project like fennec, surely you'd want to build it for Ubuntu to run it on Ubuntu anyway?
[12:52] <infinity> mjrosenb: Since an Android build wants bionic, which means running shims and other horrors.
[12:52] <mjrosenb> infinity: we don't build for ubuntu, ubuntu does :-p
[12:53] <infinity> s/Ubuntu/glibc/? :P
[12:53] <mjrosenb> bionic?
[12:53]  * mjrosenb googles
[12:53] <infinity> bionic is Android's libc.
[12:53] <infinity> It's not even remotely compatible with glibc.
[12:53] <mjrosenb> FUN.
[12:53] <infinity> There is a project that produces a disturbing translation shim that allows glibc systems to run bionic binaries with an LD_PRELOAD.
[12:53] <infinity> It's not pleasant.
[12:54] <infinity> I don't recommend it for a project you actually have the source to.
[12:54] <mjrosenb> we already have NSPR
[12:55] <infinity> mjrosenb: Err, NSPR doens't give you portability at runtime, but at build-time.
[12:55] <infinity> A bionic-using nspr won't do you a lick of good on a glibc system.
[12:56] <mjrosenb> yeah, but I don't think it has ever been our goal to have a single executable that runs on all arches.
[12:56] <infinity> (bionic is vaguely BSD-derived, think about how well it wouldn't work to take a binary from FreeBSD and run it on Linux, even if you had the kernel syscalls emulated)
[12:56] <infinity> No, it shouldn't be your goal to run a binary on multiple arches.  I agree.
[12:56] <infinity> Hence why I'm suggesting you might just want to rebuild it.
[12:56] <infinity> Cause libc6:armel still won't be bionic, so multiarch isn't going to help you here.
[12:57] <mjrosenb> http://pastebin.mozilla.org/2001793
[12:58] <mjrosenb> ahh. yes, but I like testing in an environment that is as close to what we'll be seeing in a shipping product as possible
[12:58] <mjrosenb> the js engine doesn't really have to deal with libc that much
[12:58] <mjrosenb> but it does need to deal with the likes of math.sin math.atan2
[12:58] <infinity> The wrapper lies, it's linux-ti-omap4-tools-3.5.0-215
[12:58] <mjrosenb> where the armel/armhf distinction comes into play
[12:59] <infinity> Oh, wait.  You're doing this to test for Android?
[12:59] <mjrosenb> yup.
[12:59] <infinity> Then you should build an Android chroot.
[12:59] <mjrosenb> that sounds neat.
[12:59] <infinity> Testing against glibc won't really tell you anything.
[12:59] <mjrosenb> as previously stated, I have basically 0 interaction with glibc.
[13:00] <mjrosenb> but I *am* intrigued by the concept of an android chroot.
[13:00] <infinity> Well, you must have some, or would wouldn't care about ABI.
[13:00] <infinity> Since if you were talking to the kernel directly, it's meaningless.
[13:00] <mjrosenb>   Error: sys_perf_event_open() syscall returned with 19 (No such device).  /bin/dmesg may provide additional information.
[13:00] <mjrosenb> :(
[13:01] <infinity> I didn't say perf would work, just pointed at the package that ships it!
[13:01] <infinity> (Sorry, I haven't slept in a while, that's about as helpful as I can be right now)
[13:01] <mjrosenb> as previously stated, there are math functions that are called that I need to be able to call correctly.
[13:01] <infinity> I should probably nap instead of being flip on IRC.
[13:01] <mjrosenb> not a problem, I may have to build my own kernel, wouldn't be the first time
[13:02] <infinity> Well, you'll also want an Android kernel for your test environment, so yeah.
[13:02] <infinity> Though, Linaro provides Panda Android builds that might be up your alley.
[13:02] <mjrosenb> well, I like using linux because it has a sane debugging strategy
[13:03] <suihkulokki> the disturbing shim thing is called libhybris: https://github.com/stskeeps/libhybris
[13:03] <suihkulokki> currently does libgles and stuff, but should be adabtible for any libraries
[13:05] <mjrosenb> right now, getting perf to work is a higher priority.
[13:46] <mjrosenb> was the source for linux-image-3.5.0-215-omap4 provided by linaro?
[15:16] <Jef91> Morning folks sfeole are you around?
[15:16] <sfeole> Jef91: i am
[15:17] <Jef91> sfeole: I was told you are the one to speak to about finding current docs on how the Ubuntu fastboot image is created for flashing to the nexus 7
[15:21] <sfeole> Jef91: hm, give me a few
[15:21] <Jef91> Sure sfeole - I'll be lurking for the better part of today.
[17:53] <mjrosenb> huh, was CONFIG_PERF_COUNTERS removed from the kernel?
[18:47] <mjrosenb> unrelatedly, is there a way to un-brick a chromebook that does not involve re-initializing all of chrome's state?
[19:57] <mjrosenb> ok, I have built my own kernel, but I am not sure how to get a bootable uimage out of it
[19:58] <mjrosenb> oh, make uImage, evidently
[20:03] <vanhoof> mjrosenb: https://code.launchpad.net/~ubuntu-nexus7/ubuntu-nexus7/build_script
[20:03] <vanhoof> look at the abootimg bits
[20:04] <vanhoof> line 71
[20:06] <vanhoof> mjrosenb: http://paste.ubuntu.com/1445967/
[20:06] <mjrosenb> make uimage sounds much easier
[20:07] <vanhoof> mjrosenb: likely, but just givin' ya whats easiest for me :)
[20:07] <mjrosenb> well, thank you for that
[20:08] <mjrosenb> hopefully, i'll remember that if i'm ever in a situation where that is more aprpriate than make uImage.
[20:19] <mjrosenb> tar -xzvf $TARBALL $packaged_path/initrd.img-$kver $packaged_path/vmlinuz-$kver
[20:19] <mjrosenb> that makes it look like the initrd is a tarball?
[20:19] <mjrosenb> oh no
[20:19] <mjrosenb> i am a fool $TARBALL is a tarball.  it has two files in it
[20:20] <mjrosenb> vanhoof: you happen to know anything about perf?
[20:28] <Tassadar> did password/user in raring for nexus 7 changed? It says "Login incorrect" when I try ubuntu/ubuntu
[20:31] <vanhoof> Tassadar: should boot to oem-config
[20:31] <vanhoof> Tassadar: choose your own user/pass
[20:31] <Tassadar> yeah, it does not start GUI, it just stays in tty1, so I am trying to find out what is wrong
[20:32] <vanhoof> first boot is a bit slow
[20:32] <Tassadar> yeah, I know, but not 5-10 minutes slow
[20:32] <vanhoof> i sometimes see a few sec delay from tty1 to oem-config on vt7 (i assume)
[20:32] <vanhoof> yeah not that slow
[20:32] <vanhoof> oem/oem should get you in
[20:32] <vanhoof> but it should launch oem-config
[20:34] <Tassadar> well, it does not, so I am trying to log in to tty1 to find what went wrong
[20:34] <Tassadar> (it might not be [probably is not] ubuntu issue though)
[20:39] <Tassadar> well, I guess I'll just chroot into it from recovery and change the password/create my own user
[20:42] <mjrosenb> ok, different approach, does anyone have perf working on an omap4 running 12.10?
[20:44] <Tassadar> oh, yeah, I guess that read-only root is not such a great idea :)
[20:46] <mjrosenb> relatedly, I followed the directions at http://seabright.co.nz/2011/03/29/building-the-ubuntu-pandaboard-kernel/ -- how do I build an initrd now?
[20:54] <vanhoof> Tassadar: how did you flash the device
[20:55] <vanhoof> Tassadar: make sure cmdline is tty0 if you came from quantal
[20:55] <Tassadar> it's okay now
[20:55] <vanhoof> ah ok
[20:55] <Tassadar> onboard still does not show up in oem-config for me, though
[20:55] <vanhoof> fresh flash?
[20:55] <Tassadar> yeah, basically
[20:55] <vanhoof> i flashed friday on 8gb model, no issues w/ onboard
[20:58] <vanhoof> mjrosenb: played w/ perf on x86 not on arm, but should be in linux-tools binary wise
[20:58] <vanhoof> linux-tools-nexus7 iirc
[21:09] <Tassadar> all the ext4 partitions on my nexus7 has the same UUID, what the hell Oo
[21:09] <mjrosenb> vanhoof: http://pastebin.mozilla.org/2002447
[21:10] <vanhoof> mjrosenb: looks like we need
[21:10] <vanhoof>   Fatal: No CONFIG_PERF_EVENTS=y kernel support configured?
[21:10] <vanhoof> mjrosenb: mind opening a bug against lp/ubuntu-nexus7 ?
[21:12] <mjrosenb> vanhoof: this is on a pandaboard.
[21:13] <mjrosenb> and;
[21:13] <mjrosenb> mrosenberg@panda:~$ grep CONFIG_PERF_EVENTS /boot/config-3.5.0-215-omap4
[21:13] <mjrosenb> CONFIG_PERF_EVENTS=y
[21:14] <mjrosenb> so unless /boot/config-`uname -r` is out of sync with the kernel, I should have that.
[21:14] <vanhoof> ah i thought you were talking n7
[21:15] <vanhoof> will have to look at omap4
[21:15] <mjrosenb> I realize that the perf event system is basically totally hosed on omap4
[21:16] <mjrosenb> but I just need the timer-based perf working
[21:27] <Tassadar> vanhoof: could you please check which version of onboard is installed on your n7?
[21:28] <mjrosenb> so nobody uses a pandaboard in here/
[21:29] <SailorMoon> lol
[21:29] <SailorMoon> How do i install the nightlies?
[21:30] <SailorMoon> i downloaded them in .gz format or whatever and every tool i have to open a .gz shows a .raw file
[21:30] <SailorMoon> i dunno how to get an .img from them
[21:43] <vanhoof> SailorMoon: https://launchpad.net/~ubuntu-nexus7/+archive/ubuntu-nexus7-installer
[21:43] <vanhoof> Tassadar: gimme a sec, charging atm
[21:45] <Tassadar> it looks like something crashes, because a while after I tap into the textfield, the windows lose the decorations (the title bar)
[21:47] <vanhoof> Tassadar: want an older nightly?
[21:48] <Tassadar> hmm, yeah, I suppose I could try that
[21:48] <vanhoof> i need to let this guy charge up for a bit
[21:48] <mjrosenb> speaking of which, does the upgrade process know how to upgrade the kernel on a chromebook
[21:49] <vanhoof> mjrosenb: doubtful
[21:49] <vanhoof> at least I dont think so
[21:49] <mjrosenb> and if not, I assume that I need to do it myself
[21:49] <vanhoof> i could be wrong
[22:03] <mjrosenb> is there a time of the week when people knowledgable about the pandaboard or chromebook would be online/
[22:03] <vanhoof> mjrosenb: january 2nd? ;)
[22:03] <vanhoof> mjrosenb: not sure, no cb experience here myself
[22:07] <vanhoof> Tassadar: http://people.canonical.com/~vanhoof/tassadar/UbuntuNexus7.tar.gz
[22:07] <vanhoof> Tassadar: from thursday'ish last week
[22:07] <Tassadar> thanks
[22:32] <Tassadar> nah, does the exact same thing :(
[22:32] <vanhoof> :\
[22:33] <vanhoof> i get through just fine
[22:33]  * vanhoof wtfs
[22:33] <Tassadar> it is probably my fault, I am dual-booting it and probably got something wrong
[22:36] <Tassadar> seems kinda weird though, it is doing exactly the same thing as it did when it didn't work for anyone
[23:01] <inph^> are there any nexus 7 ubuntu forums?
[23:19] <mjrosenb> checking whether the chosen combination of compiler flags (-march=armv6 -mfpu=vfp -mfloat-abi=hard) works... configure: error: no
[23:19] <mjrosenb> :-/
[23:26] <infinity> mjrosenb: Do I want to know why you're targetting v6?
[23:28] <mjrosenb> infinity: because i have a raspberry pi.
[23:28] <infinity> (Though, that combination should work, in theory, it's what Raspbian uses)
[23:28] <infinity> I'd assume the configure test itself is doing something silly.
[23:28] <infinity> Like possibly tacking on a -mfpu=neon or something? :P
[23:29] <mjrosenb> configure:5745:1: sorry, unimplemented: Thumb-1 hard-float VFP ABI
[23:30] <infinity> mjrosenb: Give it a -marm
[23:32] <mjrosenb> i already tried that, it produced executables that don't run :/
[23:32] <infinity> mjrosenb: Though, if you're cross-compiling from Ubuntu, you may find that you'll also end up compiling in static bits from our toolchain, which are v7/thumb-2, and it will all fail to run on the Pi anyway.
[23:32] <infinity> mjrosenb: Jinx. :P
[23:33] <mjrosenb> ugh.. -march=armv6 should mean 'don't do that'
[23:33] <infinity> "Don't link the static bits that you need to run the binary" is a tall order.
[23:33] <infinity> libgcc_s, crt*.o, etc.
[23:34] <mjrosenb> i mean, how does a gcc that can target both x86 and x64 handle that?
[23:34] <infinity> Well, crt*.o should be pure ARMv5 or so, but you get my point.
[23:34] <infinity> biarch GCC relies on having two copies of everything.
[23:34] <infinity> As does our biarch armel/armhf GCC.
[23:34] <infinity> But ours was never designed to target older CPUs.
[23:34] <infinity> Just as a biarch Ubuntu x86 GCC can
[23:34] <infinity> 't actually build binaries for i386.
[23:35] <infinity> Well, probably not.  Again, it depends on if any of the static bits use [456]86 instructions.
[23:35] <infinity> Which, in the ARM case, they do use v7 bits.
[23:36] <mjrosenb> this is a toolchain acquired from emdebian from well before ubuntu properly supported cross compilation
[23:36] <infinity> An armhf one though, right?
[23:36] <infinity> Debian's armhf has always been armv7-a/thumb-2
[23:37] <mjrosenb> armel, with -mfloat-abi=hard
[23:37] <infinity> As has nearly everyone's, to be fair.  Raspbian is one of the only strange attempts to do armhf on v6.
[23:37] <infinity> mjrosenb: Err, what?  "armel with -mfloat-abi=hard" *is* armhf.
[23:38] <mjrosenb> what is the difference/
[23:38] <mjrosenb> *difference?
[23:38] <infinity> Or do you mean this is an ancient compiler that was only armel?  If so, you're producing binaries that don't run for other reasons.
[23:38] <infinity> Either because the static bits aren't armhf or because you're cooking in the wrong path to the PI.
[23:39] <infinity> What's the failure mode when you try to run the binaries?
[23:39] <mjrosenb> this compiler has been producing binaries that have worked on armv7el and armv7hf systems for quite some time.
[23:39] <mjrosenb> sigill
[23:39] <mjrosenb> looks like it is getting confused about thumb mode.
[23:39] <infinity> Or that it's compiling in some v7 bits.
[23:39] <mjrosenb> oh hey
[23:39] <mjrosenb> i am using the armhf compiler
[23:40] <infinity> This is a well-known problem among Pi people trying to cross from Ubuntu.
[23:40] <mjrosenb> sounds reasonable
[23:40] <infinity> You can manually copy various static bits like libgcc from your Raspbian system to your cross environment.
[23:41] <infinity> There's also a Raspbian cross toolchain.
[23:42] <infinity> That targets the right thing by default.
[23:42] <mjrosenb> yeah, as hacked as this system is, i don't like having programs installed that aren't managed by my package manager
[23:43] <mjrosenb> i'll have to find some way of making a .deb out of the cross toolchain
[23:58] <ubuntubhoy> does anyone here have any input on the Nexus 7 install wiki page ?