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