**** BEGIN LOGGING AT Wed Mar 06 02:59:58 2013 Mar 06 12:13:11 ogra_: are you around? Mar 06 12:20:37 xnox: No I'd say ogra_ was more oblong ish Mar 06 13:55:30 xnox, i'm here now Mar 06 17:06:27 chm, that's weird, I'm getting crc error when trying to extract rootfs.tar.gz in Nexus 7's daily image Oo Mar 06 17:17:19 ogra_: has the way nexus 7 image is built changed lately? Mar 06 17:17:37 nope Mar 06 17:27:46 then what the hell am I doing wrong Oo Mar 06 17:28:30 i'll take a deeper look after UDS tomorrow or friday Mar 06 17:29:20 okay, thanks Mar 06 19:01:09 I figure this would be the best place to ask(since people develop on desktop for ES2 devices all the time): What's an easy way to use OpenGL ES2 on ARM and desktop? What OGL version does the desktop need to be to do ES2, 3.0? I'm from the land of OGL1 and D3D9... Mar 06 19:12:04 the *easiest* way? install the EGL/GLES2 packages for Mesa and use llvmpipe as the backend.. that is slow as poop, but it'd work. Mar 06 19:13:01 most of the desktop composition engines like Compiz use ES2 right now, there's not a good deal of point using ES3.. all it adds is (guaranteed) higher precision shader support and a few extra useful functions that already exist in most ES2 implementations Mar 06 19:14:24 Well my computer is fast and mobile things are slow... so in a way that works out. I guess I'll stick with ES2 only since a lot doesn't support ES3. Mar 06 19:33:51 Found mesa-utils-extra , has es2gears, es2_info and es2tri in it , yay it "just werks" I get 850 fps instead of 4800 fps, plenty usable Mar 06 20:19:42 anyone here used cdebootstrap --foreign and then something like schroot to get into the filesystem and continue emulated under qemu? Mar 06 20:20:53 why would we ? there are way better tools (qemu-debootstrap from qemu-user-static) Mar 06 20:24:59 well, I have my reservations about qemu-debootstrap as it stands (I usually opencode what it does in a more efficient way, derived from how schroot manages it...) Mar 06 20:25:54 I don't like running a VM to do the work, I'd rather do it in a chroot.. and cdebootstrap handles some things slightly better. it's mostly an experiment but the damn thing keels over if you use --foreign for some reason. Mar 06 20:26:10 what VM ? Mar 06 20:26:48 it sets up your kernel via binfmt support to be able to execute armhf binaries and then just bootstraps n armhf chroot Mar 06 20:26:52 qemu VM.. like build a disk image, run a "real" kernel, then tar up what's inside the disk image kind of thing. Like rootstock did before it got the ability to chroot ;) Mar 06 20:27:00 nothing to do with VMs Mar 06 20:27:22 it just gives youz are dir you can chroot into Mar 06 20:28:02 btw qemu-debootstrap is about 160 lines too long for what it does Mar 06 20:28:21 complain to debian :) Mar 06 20:28:33 the original i wrote was like 4 lines Mar 06 20:28:47 when they took it they bloated it Mar 06 20:29:05 loic seemed to get hold of it. he wasn't "debian" when he did that ;) Mar 06 20:29:19 well, whatever :) Mar 06 20:29:32 he pushed it to debian Mar 06 20:29:56 (saving us the maintenance ... so i'm fine with a 160 line overhead) Mar 06 20:31:08 anyway regardless, it's not the copying of the qemu binary into the right place I have a problem with it's that cdebootstrap doesn't seem to work.. probably because nobody uses it. If I do it all native it has a real and measurable performance advantage.. but all the docs say "do --foreign and then run that output on a real system" Mar 06 20:31:33 problem is that second step fails by going in via qemu-enabled chroot AND on a real native system Mar 06 20:32:09 well, i doubt anyone in ubuntu uses it Mar 06 20:32:17 so better complain to debian Mar 06 20:32:29 I can't imagine it is totally broken because live-build uses it Mar 06 20:32:42 I guess I'll go ask the debian guys :) Mar 06 20:33:02 btw what's the status on rootstock, I thought it was dead as a doornail but it seems semi-actively developed (there's a GUI!?) Mar 06 20:33:36 rootstock is long dead Mar 06 20:33:41 like 2 years or so Mar 06 20:34:35 code committed to bzr in 2012 though.. I know you don't touch it anymore I wondered if it was sanctioned or just some guys poking at the old code Mar 06 20:35:03 i think vanhoof keeps it in zombie state still Mar 06 20:35:28 i handed it over to him after it was largely unmaintained for a year Mar 07 00:47:26 nexus7 charging dock is available, it keeps the usb port free - https://plus.google.com/112773496741623034196/posts/9iyD4fC688i Mar 07 00:48:36 thats pretty cool Mar 07 01:50:46 An HP t410 "thin client" just landed on my desk, and I want to bypass the HP crap and netboot images a la PXE. A quick google suggests nobody has jailbroken these yet. Anybody here heard any diferent? Mar 07 01:51:46 Oh look, the menus give you a root shell Mar 07 01:57:30 OK, so its existing image is booting off mtdblock, and it's got a 2.6.37-atlas uImage in /boot Mar 07 01:57:42 That means it's using u-boot as the bootloader, right? Mar 07 02:00:05 twb: Seems plausible. Mar 07 02:00:35 I can see the mtdblockN's but I don't know where I'd find the uboot config file (if there is one) Mar 07 02:03:03 twb: Well, there could be an external config file on the same partition at the u-boot binary, if it's loading in the "first FAT partition" mode, or it could be burned into firmware, and u-boot has no config file, cause you're expected to setenv/saveenv from the u-boot prompt. Mar 07 02:03:23 twb: The latter could prove problematic if there's no way to SEE a u-boot prompt. Mar 07 02:03:25 * twb runs blkid on all the block devices he can dfind Mar 07 02:03:43 Apparently files.sotmarket.ru/instr/nettopy/hp/manual_hp_t410.pdf confirms that it's uboot Mar 07 02:07:16 Can only see a ext3 filesystem and a filesystem.sq inside it Mar 07 02:07:35 And yeah, when you boot it up, the screen doesn't appear to turn on until X starts Mar 07 02:07:58 (It's a single plastic box with an LCD and an arm computer inside; I haven't taken the housing off yet, so I dunno if there- Mar 07 02:08:14 aha, mtdblock5 is a uboot/ppcboot Mar 07 02:10:14 no sign of a fat with uboot config file yet Mar 07 02:32:12 Sweet, found the uboot config tools -- they are fw_* not u*[bB]oot* which is why I didn't spot them **** ENDING LOGGING AT Thu Mar 07 02:59:58 2013