**** BEGIN LOGGING AT Fri Nov 30 02:59:58 2012
Nov 30 05:09:44 <Zero_Chaos> lilstevie: you still here
Nov 30 05:09:55 <lilstevie> yes
Nov 30 05:09:59 <Zero_Chaos> <*>   Broadcom 4329/30 wireless cards support
Nov 30 05:09:59 <Zero_Chaos> (/lib/firmware/fw_bcmdhd.bin) Firmware path
Nov 30 05:10:00 <Zero_Chaos> (/lib/firmware/nvram.txt) NVRAM path
Nov 30 05:10:07 <Zero_Chaos> it builds the firmware in
Nov 30 05:10:11 <Zero_Chaos> happy birthday
Nov 30 05:10:13 <Zero_Chaos> sorry it took so long
Nov 30 05:10:16 <lilstevie> nope it doesn't
Nov 30 05:10:23 <Zero_Chaos> lol
Nov 30 05:10:29 <lilstevie> that is the reference paths to where it will find it in the filesystem when you boot
Nov 30 05:10:41 <lilstevie> I dare you to remove those firmware files after the kernel is built
Nov 30 05:10:59 <Zero_Chaos> dare huh?
Nov 30 05:11:15 <lilstevie> :p
Nov 30 05:11:27 <lilstevie> because I know it will be looking for those files in the filesystem
Nov 30 05:11:40 <lilstevie> meaning boot after deleting them, you will have no wifi
Nov 30 05:12:41 <Zero_Chaos> interesting challenge. I've never in my life seen a driver that allows you to set a random name for the firmware file.... but perhaps this is one like that
Nov 30 05:13:35 <lilstevie> you are talking about a driver that is made for android, there is nothing sane about it
Nov 30 05:13:36 <Zero_Chaos> I don't see a call to udev to pickup the firmware but I may just be missing it
Nov 30 05:13:48 <Zero_Chaos> drivers are made for linux
Nov 30 05:13:54 <Zero_Chaos> android is just a cute little gui
Nov 30 05:14:02 <lilstevie> android is a userspace
Nov 30 05:14:22 <Zero_Chaos> well yes and no, there is still a lot of linux like userspace
Nov 30 05:14:24 <lilstevie> android doesn't even use libc, they use their own custom implementation
Nov 30 05:14:38 <Zero_Chaos> yeah so does everything embedded, that doesn't mean it's not linux
Nov 30 05:14:42 <lilstevie> but still, the driver is for android
Nov 30 05:14:51 <Zero_Chaos> it's a userspace driver?
Nov 30 05:14:57 <Zero_Chaos> why am I recompiling my kernel then?
Nov 30 05:14:58 <lilstevie> as in, androids stupid custom libs, and filesystem layout
Nov 30 05:15:33 <lilstevie> up until recently bcmdhd class drivers didn't work with network manager without patches
Nov 30 05:15:58 <Zero_Chaos> yeah but nm sucks ;-)
Nov 30 05:16:29 <lilstevie> no, in this case it is the driver that sucks
Nov 30 05:16:39 <lilstevie> to android it is just an ethernet card interface
Nov 30 05:16:51 <Zero_Chaos> well the driver isn't mac80211/nl80211/etc so it's no surprise
Nov 30 05:17:04 <Zero_Chaos> yeah, that's why these things are so loved
Nov 30 05:18:42 <Ethernin> freakin android is a mess
Nov 30 05:18:52 <Zero_Chaos> android sucks like hell
Nov 30 05:18:58 <Ethernin> why the hell can't they just make it full blown linux already/?!?!
Nov 30 05:19:07 <Zero_Chaos> let's make a pwnphone android rom
Nov 30 05:19:09 <Ethernin> and what the hell ever happened to ubuntu mobile anyway??
Nov 30 05:19:12 <Ethernin> lol
Nov 30 05:19:20 <Ethernin> have u seen um
Nov 30 05:19:22 <Ethernin> fuck
Nov 30 05:19:25 <Ethernin> what is it called
Nov 30 05:19:28 <Ethernin> dsploit
Nov 30 05:19:30 <Ethernin> that's it
Nov 30 05:19:34 <Ethernin> pentesting android rom
Nov 30 05:19:43 <Zero_Chaos> Ethernin: hey
Nov 30 05:19:44 <Ethernin> course it does no wireless packet injection whatsoever
Nov 30 05:19:49 <Zero_Chaos> Ethernin: dude, check what channel you are in
Nov 30 05:20:31 <Ethernin> seriously though, does anyone here know what happened to ubuntu mobile?  are they working on releasing a ubuntu for phones?
Nov 30 05:22:02 <lilstevie> fwiw Zero_Chaos I thought you may want a little more real evidence of my claims
Nov 30 05:22:04 <lilstevie> module_param_string(firmware_path, firmware_path, MOD_PARAM_PATHLEN, 0660);
Nov 30 05:22:04 <lilstevie> module_param_string(nvram_path, nvram_path, MOD_PARAM_PATHLEN, 0);
Nov 30 05:22:15 <lilstevie>  /* load firmware and/or nvram values from the filesystem */
Nov 30 05:22:48 <lilstevie> the last was meant to be first
Nov 30 05:23:36 <Zero_Chaos> lilstevie: I guess it makes some sense though. considering it has to understand that messed up hierarchy in android and the slightly more sane standard linux one.
Nov 30 05:23:46 <lilstevie> yes
Nov 30 05:23:49 <lilstevie> that is the point
Nov 30 05:24:09 <lilstevie> although the config you showed seems to have more than what it is meant to defined
Nov 30 05:24:22 <lilstevie> bcmdhd is meant to only be the path to the folder
Nov 30 05:24:37 <Zero_Chaos> lilstevie: it was what I pulled from /proc/config.gz
Nov 30 05:24:37 <lilstevie> older versions (bcm4329 bcm4330) were full filename
Nov 30 05:24:49 <lilstevie> I didn't say it wasn't
Nov 30 05:24:53 <lilstevie> it will work all the same
Nov 30 05:25:39 <Zero_Chaos> lilstevie: this is from a 3.1.10 kernel, not that old but not new
Nov 30 05:25:59 <lilstevie> you missed what I said bcmdhd is new
Nov 30 05:26:19 <lilstevie> prior to that it was bcm4329 or bcm4330
Nov 30 05:26:34 <Zero_Chaos> lilstevie: oic, interesting
Nov 30 05:26:47 <lilstevie> and I am aware about the kernel, this is the newest nvidia is working with at present
Nov 30 05:26:50 <lilstevie> which is silly
Nov 30 05:26:55 <lilstevie> but meh
Nov 30 05:27:59 <Zero_Chaos> yeah, now I just need to hack it up to work with compat-drivers and then no care. :-)
Nov 30 05:28:06 <Zero_Chaos> but that seems a lot harder than expected
Nov 30 05:28:07 <Ethernin> lilstevie, have u tried recompiling the android kernel with usb wifi options?  / MAC80211 / CFG80211?
Nov 30 05:28:21 <Zero_Chaos> Ethernin: we had the alfa working fine yesterday
Nov 30 05:28:21 <Ethernin> just curious, i know source is kinda hard to come by as far as i know
Nov 30 05:28:30 <Zero_Chaos> Ethernin: it is pretty much the same kernel
Nov 30 05:29:05 <Ethernin> ya, the kernel on the android 4.whatever i was working on was something weird like 3.0.8
Nov 30 05:29:18 <Ethernin> but ya
Nov 30 05:29:53 <Zero_Chaos> Ethernin: considering this kernel is reasonable close to android's kernel, I'm pretty confident if I can make compat-wireless work for it I can do it on android
Nov 30 05:30:54 <lilstevie> Ethernin, for the tf201 I do, I compile for most usb wireless devices
Nov 30 05:31:09 <Ethernin> dank
Nov 30 05:31:31 <Ethernin> well heck, after this nexus 7 ill have to get back to work turning the SG3 into the next pwnphone
Nov 30 05:31:42 <Ethernin> at least until jolla comes out with the next N900
Nov 30 05:31:58 <Ethernin> the motorolla atrix is not bad either
Nov 30 05:32:21 <Ethernin> HTC one x+ is fast but no mircosd, and you can't take out the battery!
Nov 30 05:33:40 <Zero_Chaos> Ethernin: moto droid4?
Nov 30 05:33:41 <Zero_Chaos> :-)
Nov 30 05:33:52 <Zero_Chaos> Ethernin: has a keyboard and good battery life. but it's a bit slow
Nov 30 05:33:56 <Ethernin> !?!?
Nov 30 05:33:58 <Ethernin> dual core?
Nov 30 05:34:07 <Ethernin> ya but isn't it verizon only?
Nov 30 05:34:16 <Zero_Chaos> I think not, but not really sure
Nov 30 05:34:47 <Ethernin> i looked into droids for a while and pretty sure they're verizon only which is a major bummer
Nov 30 07:59:50 <dholbach> good morning
Nov 30 08:29:47 <davecheney> raring-29-nov-nexus-7 image is busted :(
Nov 30 08:30:02 <davecheney> heroic video corruption once it struggles to the desktop
Nov 30 08:56:06 <ogra_> davecheney, yes, known
Nov 30 08:56:41 <ogra_> davecheney, thats the reason we are not making much noise about these images yet ;)
Nov 30 08:57:54 <ogra_> davecheney, the more important fact is that you got through the installer and into the desktop, thanks for the feedback !
Nov 30 08:58:48 <davecheney> ogra_: well, glad I could help
Nov 30 08:59:11 <ogra_> i'll add the images to the channel topic once they are good enough for usage
Nov 30 08:59:23 <ogra_> (and there will be blog posts etc)
Nov 30 08:59:35 <davecheney> cool
Nov 30 09:00:08 <davecheney> ogra_: turns out that I have two nexus 7's
Nov 30 09:00:08 <ogra_> bug 1065638 btw
Nov 30 09:00:11 <ubot2> Launchpad bug 1065638 in ubuntu-nexus7 "Unity panels don't display visuals" [Critical,In progress] https://launchpad.net/bugs/1065638
Nov 30 09:00:12 <davecheney> so expect more bug reports
Nov 30 09:00:18 <ogra_> yay, great !
Nov 30 09:00:29 <davecheney> ogra_: u canonical ?
Nov 30 09:00:33 <ogra_> yep
Nov 30 09:00:37 <davecheney> me too
Nov 30 09:01:05 <davecheney> oh fuck, i just quit onboard
Nov 30 09:01:06 <lilstevie> ogra_, turns out that I have no problems with plymouth because I had FRAMEBUFFER=y in my initramfs-tools config
Nov 30 09:01:10 <davecheney> trying to make it always on
Nov 30 09:01:27 <ogra_> enable the "floating button" option
Nov 30 09:01:40 <ogra_> always on will get in your way
Nov 30 09:01:40 <lilstevie> ogra_, so yes, it does work with quantal as well
Nov 30 09:01:52 <davecheney> yeah, i was trying, but I hit quit, instead of prefs
Nov 30 09:02:27 <ogra_> lilstevie, yeah, my prob is that our bootimg cant be bigger than 8M and the wlan driver is compiled into the kernel ... which gives me a 4M vmlinuz
Nov 30 09:02:40 <lilstevie> ogra_, yeah ouch
Nov 30 09:02:48 <ogra_> setting FRAMEBUFFER pulls enough stuff in to make my initrd to big
Nov 30 09:03:06 <lilstevie> ogra_, yeah, understood my initrd is 8MB on its own
Nov 30 09:03:25 <ogra_> *envy*
Nov 30 09:03:37 <ogra_> but your boot will be slower :P
Nov 30 09:03:44 <lilstevie> ogra_, it is the trade off
Nov 30 09:04:33 <lilstevie> ultimately I find that it is worth it
Nov 30 09:04:39 <lilstevie> but that is my opinion
Nov 30 09:04:48 <ogra_> instead of having to hack defaults ? yeah
Nov 30 09:05:15 <ogra_> we have way to much useless stuff in our initrd
Nov 30 09:05:39 <lilstevie> it isn't only that, from time to time I do find myself using android
Nov 30 09:05:47 <lilstevie> which  is certainly much easier to manage
Nov 30 09:06:14 <lilstevie> and size
Nov 30 09:06:25 <lilstevie> for a very long time I was fighting size with the tf101
Nov 30 09:06:55 <lilstevie> at one point I increased the size of LNX purely for the extra space required
Nov 30 09:07:42 <ogra_> well, i like to stay with the device defaults where the bootloader defines the partitioning so people dont get issues rolling back to the original OS
Nov 30 09:08:01 <lilstevie> yeah well that is what has happened this time
Nov 30 09:08:19 <lilstevie> using lvm to tie partitions together means that it is just a wipe and restore with recovery away from stock
Nov 30 09:08:45 <lilstevie> -rw-r--r--    1 root     root        7.9M Nov 30 05:39 initrd.img-3.1.10-1-transformer-tegra3
Nov 30 09:08:46 <lilstevie> -rw-r--r--    1 root     root        3.5M Nov 16 10:13 vmlinuz-3.1.10-1-transformer-tegra3
Nov 30 09:08:53 <lilstevie> wouldn't be possible before
Nov 30 09:08:56 <lilstevie> :p
Nov 30 09:11:45 <lilstevie> next step though is to trim down the kexec host kernel, I'm sure a lot of the unneeded cruft that is left in the kernel which would be used under normal boot conditions will be slowing boot down
Nov 30 12:30:52 <ogra_> xnox, so how about using the compiz wallpaper plugin in ubiquity ?
Nov 30 12:31:30 <xnox> ogra_: it already suppose to do it.
Nov 30 12:31:39 <xnox> ogra_: but nothing shows up =(
Nov 30 12:32:00 <ogra_> oh, i only saw the decoration plugin on your commandline
Nov 30 12:32:10 <xnox> ogra_: there is --background as well.
Nov 30 12:32:24 * xnox is not sure if it needs a plugin or just that command line option though
Nov 30 12:32:37 <xnox> (or whatever it is --background-img?!)
Nov 30 12:32:47 <ogra_>  wm_cmd = ['compiz', '--sm-disable', '--fast-filter', 'decor']
Nov 30 12:32:59 <ogra_> thats what i see in the merge request, did you change it ?
Nov 30 12:33:26 <ogra_> oh
Nov 30 12:33:34 * ogra_ missed wm_cmd.extend(['--bg-image', background_image])
Nov 30 12:33:41 <ogra_> ignore me :P
Nov 30 12:38:23 <hrw>  /ignore ogra_
Nov 30 12:40:05 * xnox likes hrw
Nov 30 13:24:58 <dholbach> I'm not sure if my last message actually made it here....
Nov 30 13:25:02 <dholbach> <dholbach> ogra_, is "update-manager -c -d" supposed to work on the nexus7? :)
Nov 30 13:25:04 <dholbach>  it presents me with the option to upgrade "your up-to-date, but there's 13.04" and if I click on "update..." it just exits
Nov 30 13:26:01 <dholbach> I could just go into /etc/apt/sources.list and dist-upgrade manually, but I thought I'd check the more obvious solution first
Nov 30 14:21:53 <ogra_> dholbach, sure, that should work
Nov 30 14:22:05 <ogra_> (update-manager)
Nov 30 14:25:26 <ogra_> suihkulokki, *all* image/rootfs builder tools should export FLASH_KERNEL_SKIP=true, then flash-kernel will DTRT
Nov 30 14:26:15 <ogra_> just make sure to export it somewhere in your live-build config
Nov 30 14:27:09 <suihkulokki> sounds greek to me :P
Nov 30 14:27:18 <infinity> No, that's markos.
Nov 30 14:27:33 <ogra_> hah
Nov 30 14:27:36 <suihkulokki> ogra_: you mean the bug is in linaro-media-create that should set FLASH_KERNEL_SKIP=true
Nov 30 14:27:43 <ogra_> suihkulokki, exactly
Nov 30 14:28:13 <ogra_> that will prevent flash-kernel from trying to flash/write to a bootloader partition
Nov 30 14:28:28 <suihkulokki> ok, I'll poke people to do that
Nov 30 14:28:33 <ogra_> thx
Nov 30 14:28:34 <infinity> How did we end up needing this hack with 3.0, when 2.x was fine in chroots?
Nov 30 14:28:44 <ogra_> 2.0 had that too
Nov 30 14:28:59 <infinity> Was it in our livecd-rootfs configs back then?
Nov 30 14:29:06 <infinity> Maybe I just don't remember. :P
Nov 30 14:29:09 * suihkulokki unsure which one to hate more - flash-kernel or linaro-media-create
Nov 30 14:29:29 <infinity> Oh, even livecd.sh had it.
Nov 30 14:29:30 <infinity> Alright.
Nov 30 14:29:35 <infinity> It's always sucked. :P
Nov 30 14:30:07 <ogra_> right
Nov 30 14:30:38 <infinity> Althought, we don't suppress anymore, we now dpkg-divert.
Nov 30 14:30:52 <ogra_> originally added on 2011-01-26
Nov 30 14:37:59 <dholbach> ogra_, it doesn't, but I talked to mvo about it -- nux/unity should land early next week according to didrocks
Nov 30 14:38:09 <dholbach> ogra_, they're still working on some test-suite issues
Nov 30 14:38:12 <ogra_> i hope so
Nov 30 14:38:21 <dholbach> yes, me too
Nov 30 14:38:25 <ogra_> i really want to make the alpha1 date with the images
Nov 30 14:42:10 <infinity> ogra_: Ubuntu's not doing alphas anyway...
Nov 30 14:42:32 <infinity> ogra_: Welcome to raring. :)
Nov 30 14:43:46 <ogra_> infinity, i know, but that was my point in time i have set as target for having working images
Nov 30 14:44:05 <ogra_> i still like to use milestones for scheduling ;)
Nov 30 14:44:09 <infinity> Fair enough.
Nov 30 14:44:17 <infinity> I say they should work yesterday.
Nov 30 14:44:20 * infinity waits.
Nov 30 14:44:25 <infinity> DO THEY WORK YET?!
Nov 30 14:44:33 <ogra_> they do
Nov 30 14:44:36 <ogra_> since last week
Nov 30 14:44:40 <ogra_> the desktop doesnt
Nov 30 14:44:47 <infinity> Who needs that?
Nov 30 14:44:52 <ogra_> heh
Nov 30 14:44:55 <infinity> Commandline tablets are all the rage.
Nov 30 15:26:33 <achiang> dholbach: hi, what time is the meeting today? :)
Nov 30 15:28:09 <dholbach> achiang, half an hour?
Nov 30 15:28:13 <dholbach> achiang, what's on the agenda?
Nov 30 15:28:29 <dholbach> achiang, I'll announce it on the @ubuntudev channels
Nov 30 15:28:38 <achiang> dholbach: i think we can do general q&a and also general discussion re: memory leaks
Nov 30 15:28:44 <achiang> dholbach: have you read my latest blog entry?
Nov 30 15:29:11 <dholbach> yes, I shared it through @ubuntudev too :)
Nov 30 15:29:40 <achiang> heh, ok
Nov 30 15:29:46 <achiang> kyleN_: ^^
Nov 30 15:30:14 <kyleN_> ack
Nov 30 15:40:33 <dumby88> RK2918
Nov 30 15:44:43 <dholbach> does anyone have their nexus7 on raring already? was onboard deinstalled for you during the installation too?
Nov 30 15:44:47 <dholbach> err, upgrade
Nov 30 15:49:49 <dholbach> ogra_, can you please reupload onboard into the nexus7 ppa?
Nov 30 15:49:58 <dholbach> so it picks up the new python
Nov 30 15:50:02 <dholbach> right now it's uninstallable
Nov 30 15:50:32 <dholbach> into the raring ppa pocket
Nov 30 15:53:54 <dholbach> or maybe upload it straight to the archive :)
Nov 30 15:58:58 <dholbach> ^ or anyone else in ~ubuntu-nexus7 really
Nov 30 15:59:38 <dholbach> I assume a changelog-only upload, maybe for virtkey too (have to check) will do it
Nov 30 16:00:13 <ogra_> why is there an onboard at all in the PPA ?!?
Nov 30 16:00:26 * ogra_ doesnt knwo who uploaded that
Nov 30 16:00:53 <ogra_> i have no issues with onboard on the raring images
Nov 30 16:05:52 <dholbach> ogra_, you did
Nov 30 16:05:58 <dholbach> ah no
Nov 30 16:05:59 <dholbach> sorry
Nov 30 16:06:01 <dholbach> ssweeny
Nov 30 16:06:05 <dholbach> https://launchpad.net/~ubuntu-nexus7/+archive/ppa
Nov 30 16:07:11 <ssweeny> I uploaded it at the behest of the onboard devs
Nov 30 16:13:19 <ssweeny> dholbach, what's the issue with onboard and python? was there an update?
Nov 30 16:13:35 <dholbach> no, but it can not be installed in raring
Nov 30 16:13:41 <dholbach> because it wants python << 3.3
Nov 30 16:13:52 <dholbach> a simple rebuild should do it
Nov 30 16:13:58 <ssweeny> in raring people should be using the archive version i would think
Nov 30 16:14:01 <ogra_> why ... the version in raring should outsmart the one in the PPA
Nov 30 16:14:02 <dholbach> but maybe we should just get the new version into the archive
Nov 30 16:14:10 <ssweeny> unless upstream hasn't released yet...
Nov 30 16:14:11 <dholbach> ssweeny: the version in the ppa is higher
Nov 30 16:14:17 <ogra_> ouch
Nov 30 16:14:19 <ssweeny> ah, hm
Nov 30 16:14:43 <dholbach> 0.99~tr1071-0nexus7.1 vs 0.98.2-0ubuntu1
Nov 30 16:14:45 <ssweeny> so the version in the PPA is a snapshot of an upcoming release
Nov 30 16:14:58 <dholbach> are we in touch with upstream?
Nov 30 16:15:06 <ssweeny> i was lead to believe that the release was coming soon and that it would go straight into raring
Nov 30 16:15:45 <dholbach> nothing in the sponsoring queue
Nov 30 16:15:57 <ssweeny> the snapshot has a fix for the performance issue with the ambiance theme
Nov 30 16:16:08 <dholbach> ok, shall I mail upstream and CC you?
Nov 30 16:16:27 <ssweeny> that would be great
Nov 30 16:16:32 <dholbach> alright
Nov 30 16:16:34 <dholbach> will do
Nov 30 16:19:28 <dholbach> done
Nov 30 16:21:00 <ssweeny> great, thanks dholbach
Nov 30 16:21:06 <dholbach> anytime
Nov 30 17:13:08 <bootidsa> Anyone here from meetingology today ?
Nov 30 18:37:23 <philhug> is anyone familiar with the odroid-x2 or -u2?
Nov 30 18:43:07 <Quinto68> hi someone has pcre package for arm?
Nov 30 18:43:10 <Quinto68> i have this error
Nov 30 18:43:26 <Quinto68> error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory
Nov 30 19:20:17 <Quinto68> hi someone has pcre package for arm?
Nov 30 19:20:24 <Quinto68> error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory i have this error
Nov 30 19:27:17 <lardman|home> Is there any thought to provide dual booting ability for the Nexus 7?
Nov 30 19:27:35 * lardman|home looks at the installer script
Nov 30 19:27:57 <lardman|home> Ah, I seem to remember someone mentioning that this is often asked.... :)
Nov 30 19:29:03 * Tassadar throws http://forum.xda-developers.com/showthread.php?t=2011403 at lardman|home
Nov 30 19:31:05 <lardman|home> this potentially looks to be a better bet: http://forum.xda-developers.com/showthread.php?p=34853595
Nov 30 19:31:18 <lardman|home> place the Ubuntu kernel in the recovery partition, etc.
Nov 30 19:32:01 <Tassadar> and both android and ubuntu to /data at once?
Nov 30 19:32:36 <lardman|home> yeah I'm wondering quite what the deal is there
Nov 30 19:32:58 <lardman|home> then again the link you pasted my have changed since I looked at it yesterday
Nov 30 19:33:20 <Tassadar> I am not saying that it does not work, just that it is _kinda_ dirty
Nov 30 19:33:31 <lardman|home> would be good to repartition and then install Ubuntu to its own one (as I have a 32GB device)
Nov 30 19:33:54 <Tassadar> I don't think that's really an option
Nov 30 19:35:06 <lardman|home> Tassadar: I wasn't so keen on the multiboot method of copying boot partition everytime
Nov 30 19:35:06 <[mbm]> haven't looked at the existing solutions, but it should be pretty easy to create a /data/ubuntu; android will ignore that and the ubuntu initrd would need to be altered slightly to use it as a root
Nov 30 19:35:59 <[mbm]> I don't think repartitioning is an option given that I don't see an actual partition table
Nov 30 19:36:29 <lardman|home> there are the wonderful pit files iirc
Nov 30 19:36:37 <lardman|home> though yeah, sounds quite messy
Nov 30 19:36:57 <Tassadar> lardman|home: me neither, but kexec-hardboot compatibility is already in the ubuntu-nexus7 kernel, just waiting for it to actually get to the devices
Nov 30 19:37:31 <lardman|home> if one uses chroot then presumably the Android data won't be available?
Nov 30 19:37:52 <lardman|home> s/chroot/whatever method to change the location of root
Nov 30 19:37:52 <[mbm]> depends on the chroot
Nov 30 19:38:10 <[mbm]> one fun trick is pivot_root
Nov 30 19:38:26 * lardman|home tries to remember the difference
Nov 30 19:38:28 <[mbm]> which technically only works on mount points
Nov 30 19:38:43 <[mbm]> pivot_root differs from chroot in that it's global, not just sub processes
Nov 30 19:39:01 <[mbm]> also it places the pervious root directory as a subdirectory of the new root
Nov 30 19:39:12 <lardman|home> I had to do that on the Galaxy Tab kernel to move from initrd to rootfs to boot Mer, but can't remember for the life of me now what the diff was
Nov 30 19:39:29 <lardman|home> ah yes, that sounds familiar
Nov 30 19:39:35 <[mbm]> so a common thing might be: mount /dev/root /target; pivot_root /target /initrd; umount /initrd
Nov 30 19:39:47 <Tassadar> I wanted to modify ubuntu as little as possible, so I just move the android to /media/*something* and then move in the ubuntu files :/
Nov 30 19:40:27 <[mbm]> normally you can't specify an argument to pivot_root that isn't a mount point
Nov 30 19:40:39 <[mbm]> which would make something like /media/ubuntu or /data/ubuntu annoying
Nov 30 19:40:56 <[mbm]> the workaround is amazingly simple though
Nov 30 19:41:04 <[mbm]> mount --bind /data/ubuntu /data/ubuntu
Nov 30 19:41:17 <[mbm]> and magically it's a mount point suitable for use with pivot_root
Nov 30 19:42:32 <Tassadar> would be great to get something like that into ubuntu)
Nov 30 19:42:46 <lardman|home> +1
Nov 30 19:42:55 <[mbm]> yeah, I want to see a nice dual boot solution
Nov 30 19:43:07 <[mbm]> bootloader is a different story
Nov 30 19:43:32 <Tassadar> also, mounting .img as root would be great, if that's even possible
Nov 30 19:43:43 <[mbm]> yep, that's easy
Nov 30 19:43:48 <Tassadar> do tell
Nov 30 19:44:16 <[mbm]> mount -o loop root.img /target; pivot_root /target /initrd; umount initrd
Nov 30 19:44:37 <[mbm]> as in, recompile the ubuntu kernel so that the initrd mounts the correct root device
Nov 30 19:45:36 <[mbm]> part I'm trying to figure out is if there's a better way to handle bootup than booting into a linux kernel which provides a kexec boot menu
Nov 30 19:45:54 <lardman|home> normal vs recovery partitions?
Nov 30 19:46:08 <Tassadar> then you don't even have the boot menu
Nov 30 19:46:09 <lardman|home> or you want to leave the recovery partition functionality?
Nov 30 19:46:21 <[mbm]> yeah, could put the ubuntu kernel on the recovery partition but then you lsoe access to recovery
Nov 30 19:46:47 <[mbm]> would be nice if there was a 3rd partition and entry on the existing boot menu
Nov 30 19:47:19 <Tassadar> would be nice if the bootloader was open-source)
Nov 30 19:47:30 <lardman|home> :)
Nov 30 19:47:32 <[mbm]> yeah, that's the problem
Nov 30 19:47:39 <Tassadar> ...and we had nvflash, so that we could not brick it)
Nov 30 19:48:09 <[mbm]> frmo what I can tell the hardware is technically locked, and it's simply that unlocking tells the bootloader to ignore signature checks
Nov 30 19:49:10 <Tassadar> well, it is nvidia, so...
Nov 30 19:49:14 <lardman|home> Is the loss of the recovery partition such a problem - people installing this are going to be used to flashing things I'd expect
Nov 30 19:49:34 <[mbm]> not 100% certain on that first part though, don't know if nvflash is all that's needed or if the hardware does a signature check on the botloader
Nov 30 19:50:34 <[mbm]> yeah, but it's more of an annoyance thing; if I'm dual booting and I get an ota update to android, it'll download to the /cache partition and then reboot into recovery with the /cache/recovery/command set to automatically apply it
Nov 30 19:51:06 <Tassadar> lardman|home: I don't really see the point in using recovery partition once the kexec-hardboot is there
Nov 30 19:51:08 <lardman|home> ah, I didn't realise that was how it worked
Nov 30 19:51:23 <lardman|home> Tassadar: sure
Nov 30 19:51:46 <[mbm]> Tassadar: I know what kexec is, but what's the "hardboot" part?
Nov 30 19:52:02 <Tassadar> on most android devices, normal kexec just freezes
Nov 30 19:52:29 <Tassadar> due to drivers not properly initializing, probably
Nov 30 19:52:32 <[mbm]> well yeah, arm kexec has traditionally been a bit dodgy
Nov 30 19:52:50 <Tassadar> so "kexec-hardboot" patch was made, which does full hw restart of the device between the boot
Nov 30 19:52:58 <Tassadar> basically "fastboot boot" without the fastboot
Nov 30 19:53:17 <Tassadar> gimme a second, I'll find a link to the original patch...
Nov 30 19:53:29 <[mbm]> that's interesting; any idea how it manages to avoid going into the bootloader after resetting everything?
Nov 30 19:53:59 * [mbm] grabs some lunch (bbl)
Nov 30 19:54:33 <Tassadar> kexec -e saves some info to RAM (some location where it does not get overwritten on reboot), then reboots normaly
Nov 30 19:55:11 <Tassadar> the same kernel checks for that info in early state of boot (in the decompressor), and if it is there, it decompresses the kernel from RAM
Nov 30 19:55:53 <Tassadar> ...that is how I understand it
Nov 30 19:56:11 <Tassadar> http://forum.xda-developers.com/showthread.php?t=1266827 here is the original patch
Nov 30 19:57:18 <lardman|home> thanks
Nov 30 19:58:53 <Tassadar> the con is that it needs 2 small patches in the "guest" kernel, the one which is being booted with kexec
Nov 30 19:59:46 <lardman|home> So the plan would be to place the Ubuntu kernel in the boot partition and need to patch the Android kernel?
Nov 30 20:00:59 <Tassadar> both kernels must be patches
Nov 30 20:01:02 <Tassadar> *patched
Nov 30 20:01:41 <lardman|home> sure, but which is booted?
Nov 30 20:01:48 <lardman|home> (first)
Nov 30 20:02:25 <Tassadar> I would recommend the android kernel, since it does not get updated so often and can be easily patched.
Nov 30 20:03:06 <lardman|home> fine, that makes sense, and presumably one would be able to perform a binary patch on the kernel from Android userspace?
Nov 30 20:03:26 <Tassadar> wau
Nov 30 20:03:38 <Tassadar> you just want to make it difficult :D
Nov 30 20:03:49 <lardman|home> to avoid needing to flash a new kernel whenever an update occurs
Nov 30 20:08:59 <lardman|home> re this post, any ideas on what the Ubuntu image does on first boot that might break something if it's in the recovery partition: http://forum.xda-developers.com/showthread.php?t=1266827
Nov 30 20:09:25 * lardman|home goes to look at the image now it's downloaded
Nov 30 20:09:55 <Tassadar> well it flashes boot image
Nov 30 20:10:10 <Tassadar> which it also does on every kernel/initrd update
Nov 30 20:10:17 <Tassadar> so you have to disable that
Nov 30 20:11:19 <lardman|home> Not the updater script that runs on the desktop, the image running on the device flashes the boot image too>
Nov 30 20:11:21 <lardman|home> ?
Nov 30 20:11:30 <lardman|home> s/updater/installer
Nov 30 20:11:58 <Tassadar> yes
Nov 30 20:12:06 <Tassadar> 12.10 removes the tarball-installer image
Nov 30 20:12:25 <Tassadar> and 13.04 will change kernel cmdline during installation
Nov 30 20:12:32 <Tassadar> *tarball-installer package
Nov 30 20:13:38 <lardman|home> and it can't know where the running kernel is located I guess?
Nov 30 20:13:57 <Tassadar> no
Nov 30 20:14:28 <lardman|home> ok, well at least that explains the need that chap had to reflash the Android kernel
Nov 30 20:16:07 <lardman|home> Is the move to using kexec imminent, or is it worth just hacking together a dual boot setup for the time being?
Nov 30 20:16:49 <Tassadar> I dunno where the kernel with patches gets to repositories, so...
Nov 30 20:17:25 <Tassadar> *when..ohmygodineedsomesleep
Nov 30 20:17:46 <lardman|home> :) I was just trying to parse that correctly
Nov 30 20:22:51 * [mbm] reads over the kexec threads
Nov 30 20:23:14 <[mbm]> guessing that the stock recovery kernel isn't patched for hardboot support?
Nov 30 20:23:22 <Tassadar> nope
Nov 30 20:23:27 <[mbm]> :/
Nov 30 20:24:32 <[mbm]> was hoping it would be as easy as replacing recovery with a kexec menu and then using kexec-hardboot to switch between ubuntu and recovery
Nov 30 20:25:24 <[mbm]> though there's also the pesky problem of /system/etc/install-recovery.sh which takes the existing "boot" kernel, applies a patch and writes it to recovery
Nov 30 20:25:43 <[mbm]> stupid script gets installed by an ota and run every subsequent boot
Nov 30 20:28:14 <Tassadar> anyway, heres CM10 kernel with applied kexec-harboot patch: https://github.com/Tasssadar/android_kernel_asus_grouper/commits/kexec-clean
Nov 30 20:28:46 <Tassadar> I even submitted it for review to cyanogenmod, hope it get's there
Nov 30 22:12:41 <marvin24> ogra_: can we create some nvidia-tegra-dev package with headers needed to compile the gstreamer plugins?
Nov 30 22:13:08 <marvin24> I don't want to copy them into the source, because I feal they belong to the drivers package
Nov 30 22:15:27 <marvin24> ogra-cb_: ^^^
Nov 30 22:23:19 <marvin24> basicly these ones (without the OMX_*) https://gitorious.org/nvtegra-gst/gstomx/trees/master/nv_headers
Nov 30 23:18:29 <mjrosenb> ooompf
Nov 30 23:19:15 <mjrosenb> I installed ubuntu on my chromebook using the absurd script that repartitons the disk, and fetches a bunch of tarballs
Nov 30 23:19:30 <mjrosenb> and its kernel wasn't compiled by ubuntu, was it?
Nov 30 23:19:41 <mjrosenb> I bet it just stole cros' kernel
Nov 30 23:19:51 <mjrosenb> which explains why I can't install perf on it :/
**** ENDING LOGGING AT Sat Dec 01 02:59:58 2012