[00:00] <LisaNori> infinity: Thanks.  I was just curious because when I received my nexus7, I tried connecting to my LEAP network and found that Android doesn't seem to support it.  It supports PEAP but doesn't seem to support LEAP.  Since I'm really planning to reload it with Linux,  I don't care about Android as long as Linux works. :)
[00:01] <infinity> ogra-cb: Oh, hah.  This is another case of oem-config-remove not cleaning up properly.  ubiquity recommends lvm2, so it's landing on your images.
[00:02] <infinity> ogra-cb: I bet an apt-get autoremove after installation would magically make it go away.  Maybe.  If so, we know the fix.
[00:04] <infinity> LisaNori: A quick Google implies that we've probably supported it for ~5y or so.
[00:07] <LisaNori> infinity: Ok, thanks a lot.  I should have been able to find this out myself.  I'll proceed with moving to Linux.  This should be fun!
[01:00] <liono> Hi everyone! I was thinking about getting one of those new Samsung Chromebooks to put an ARM version of Ubuntu on. I was wondering what the state of ARM ports for applications in the ubuntu repositories is like.
[01:22] <infinity> Hi everyone!  I was considering popping in to ask a question and then leaving before the person answering me finished typing.  I was wondering if this is normal practice.
[01:22]  * infinity grumbles.
[01:27] <twb> lilstevie: ping
[01:27] <twb> lilstevie: FYI, funny thing happened just now -- I can see a particular wifi AP under android, but not under ubuntu
[01:30] <twb> http://paste.debian.net/210873/ has my in-house bug report.  Anyway, feel free to ping or email me if you're interested in poking at it.
[01:35] <lilstevie> twb, feel free to look at it yourself
[01:35] <lilstevie> twb, the wifi chip is set up and initialised as it would be in android minus one thing, which should be irrelevant to your situation
[01:35] <twb> Yeah, I did for a bit but I couldn't work it out and I'm on company time atm, so I felt bad spending all day on it :-)
[01:36] <lilstevie> the only thing that isn't done is writing the mac address into the chips memory space
[01:36] <lilstevie> so it uses the built in mac
[01:37] <twb> OK
[01:38] <twb> BTW, I heard a rumour that your installer thingo for tf101 is vastly more awesome and sexy than when I installed 11.10 - is that true?
[01:42] <lilstevie> that is not true
[01:42] <lilstevie> or actually
[01:42] <lilstevie> maybe
[01:42] <lilstevie> which version did you install with?
[01:42] <twb> Hehe
[01:42] <lilstevie> 1.0?
[01:43] <twb> Whatever it was just after you renamed it
[01:43] <lilstevie> given you are using wpa_supplicant vs network manager sounds like it
[01:43] <twb> It installed 11.10 instead of pretty armhf 12.04
[01:43] <twb> Oh, I'm using wpa_supplicant just because I hate GUIs
[01:43] <twb> And I hate NM
[01:43] <lilstevie> hm
[01:43] <twb> I'm sure it defaulted to NM from your install -- i meant awesome and sexy more like it's 12.04 armhf, not relating to wifi at all
[01:44] <twb> And like the GUI is accelerated and maybe speakers or hdmi or something works now
[01:44] <lilstevie> ok sure then no
[01:44] <twb> Oh, OK.
[01:44] <lilstevie> not me
[01:44] <lilstevie> :p
[01:44] <twb> GOod think I was too lazy to try it then :-)
[01:44] <lilstevie> I have pretty much discontinued the tf101
[01:44] <lilstevie> supid tegra 2
[01:45] <twb> That's what I figured.  I will LART $coworker for lying to me
[01:45] <twb> Are you having fun on the tegra3?
[01:45] <lilstevie> there is some new installer thing, but it isn't by me, nor have I used it
[01:45] <lilstevie> that I am
[01:45] <twb> Cool
[01:47] <lilstevie> even with crippled emmc r/w tasks like compiling on average finish in 1/3 of the time quicker (ie: on a kernel compile 20min(tegra3) vs 30min(tegra2)
[01:48] <lilstevie> but with further performance tweaks that could be reduced even more
[01:50] <twb> I'm more interested in ricing the battery life higher
[01:50] <lilstevie> heh
[01:50] <twb> THe only thing that's too slow for me, is apt upgrades
[01:50] <twb> everything else is prety much just a ssh or browse to a "real" computer
[01:50] <lilstevie> there is a certain trade-off with the tegra3 for battery life
[01:50] <twb> Plus emacs, I guess.  Emacs "only" needs 80MB RAM and suchlike, so its meh
[01:51] <lilstevie> apt transactions are pretty screwed due to io crippling (on both devices)
[01:51] <twb> That combined with dpkg being SUPER anal about flushing to disk
[01:51] <twb> It's the pathological case on my btrfs VMs as well
[01:52] <lilstevie> heh
[01:52] <twb> Though in that case it seems to be less bad under 3.x than it was under 2.6.32 / 3.2
[01:52] <twb> Hm, it's running 3.2 now.  Maybe I'm just making shit up...
[01:52] <lilstevie> lol
[02:26] <cwayne> transferred bug logging info from blog to https://wiki.ubuntu.com/Nexus7/LoggingBugs
[03:39] <ptl> hello
[03:40] <ptl> is there a mailing list or forum where the ubuntu on nexus 7 is discussed?
[03:40] <ptl> could not find that in the wiki
[03:51] <twb> there's always xda forum
[07:18] <[mbm]> twb: the single xda thread is somewhat annoying to follow
[07:28] <ynezz> forums should be illegal :p
[07:35] <[mbm]> I get annoyed by these single thread things that go on for 20+ pages
[07:51] <dholbach> good morning
[10:04] <day> is there a site regarding nexus7 - ubuntu hardware support? what is fully supporter what not and so on?
[10:04] <day> supported*
[10:05] <ogra_> there is the buglist
[10:05] <ogra_> somewhere linked under the wikipage
[10:05] <day> the known issues?
[10:06] <day> wasnt sure how up2date that is
[10:06] <ogra_> many of the bugs are touched daily by our QA guys
[10:06] <ogra_> or at least they look over it very regulary
[10:07] <ogra_> essentially we only have wlan and partitally bluetooth working
[10:08] <ogra_> most if not all the rest is still waiting for someone to adopt ;)
[10:08] <ogra_> i think soimeone works on the gyro sensor stuff, but i'm not 100% sure
[10:09] <day> ogra_: gyro and gps shouldnt be toooo complicated. its not like you communicate with an unknown entity there
[10:09] <day> ogra_: anyways thanks. i will give it a shot :)
[10:09] <ogra_> well, gyro is complicated because there is absolutely nothing in userspace for it atm
[10:10] <ogra_> even if you get the device to work, there is no API or something in X so it needs some upstream development
[10:10] <ogra_> (some lib that interconnects xrandr, the sensor and xinit rotation processing)
[10:10] <ptl> so, there is no canonical-sponsored mailing list for Ubuntu on Nexus 7?
[10:10] <ogra_> s/xinit/xinput/ (sorry)
[10:10] <day> ogra_: hmm makes sense
[10:11] <ogra_> ptl, we use the normal ubuntu lists
[10:11] <ogra_> ubuntu-devel/ubuntu-devel-discuss for development discussion
[10:12] <ogra_> xnox, why do i suddenly get lvm2 andf kpartx in my arm initrds ? i cant remember it being that way with ac100 ubuntu images in precise, did we add new deps ?
[10:12] <ptl> ogra_: but the amount of unrelated stuff / noite there might be unimaginable :-/
[10:13] <ptl> *noise
[10:13] <xnox> ogra_: you shouldn't.
[10:13] <ogra_> ptl, up to now no bigger noise showed up :)
[10:13] <day> ogra_: i just realized ur a pretty active linux/ubuntu dev. thanks for all your work :)
[10:13] <ogra_> xnox, well, on the newly built images that is
[10:13] <xnox> ogra_: unless something is pulling lvm2 in.....
[10:13] <ogra_> day, heh, thanks for using it :)
[10:14]  * xnox will look.
[10:14] <ogra_> xnox, yeah, thats what i think, funnily it doesnt happen on lubuntu ac100 images
[10:14] <xnox> lolz.
[10:14] <ogra_> which build with --no-install-recommends though
[10:14] <ogra_> so i assume a new recommends somewhere in ubiquity
[10:14] <xnox> ogra_: so which images are you seeing this with? the rarings or quantals lubuntu ac100?
[10:15] <ogra_> in any case i end up with a 2.4M initrd, thats likely to big (or at least at the edge for becoming unbootable)
[10:15] <ogra_> the raring nexus7 testbuilds
[10:15] <lilstevie> day, tbh the GPS isn't 100% straight forward either
[10:16] <day> lilstevie: why is that?
[10:16] <lilstevie> day, get the GPS chip to output NMEA over the UART :)
[10:17] <day> lilstevie: that doesnt sound to complicated. its a standard amateur 8-bit uC hobby project
[10:17] <lilstevie> day, once you get that it will be straight forward, but getting it to turn on correctly isn't
[10:18] <lilstevie> day, you are meant to be able to just wiggle a gpio and it comes to life
[10:18] <lilstevie> :p
[10:18] <ogra_> xnox, http://people.canonical.com/~ubuntu-archive/livefs-build-logs/raring/ubuntu-nexus7/20121119.5/livecd-20121119.5-armhf.out the update-initramfs call at the end runs with -v
[10:18] <day> lilstevie: you are meant to be able to just wiggle a gpio. is that hard via linux? :p
[10:18] <ogra_> (ignore the abootimg noise)
[10:18] <lilstevie> day, no, wiggling the gpio is just ineffective
[10:19] <lilstevie> aka missing something
[10:19] <ogra_> xnox, ac100 for comparison http://people.canonical.com/~ubuntu-archive/livefs-build-logs/raring/lubuntu-ac100/20121119/livecd-20121119-armhf.out
[10:19] <lilstevie> day, someone with enough determination could probably get it going though
[10:20] <day> lilstevie: well how else do you want it to do? the gps chip is wired to some pin which has to do it :/
[10:20] <xnox> ogra_: yeah it's funny =)
[10:20]  * ogra_ sighs about all that arabic spam 
[10:20] <lilstevie> day, you are missing the point, following the gps enable isn't enough
[10:20] <lilstevie> day, so spend some time following it being enabled in android :p
[10:21] <xnox> ogra_: so oem-config is installed, that depends on ubiquity, which in turn recommends lvm2 & dmraid
[10:21] <ogra_> right, so as i assumed, its recommends
[10:21] <xnox> ogra_: but you say you install with --no-install-recommends
[10:21] <ogra_> not on nexus
[10:21] <xnox> ah.
[10:21] <ogra_> lubuntu-desktop enforces it
[10:21] <ogra_> nexus uses ubuntu, ac100 lubuntu
[10:22] <lilstevie> day, point is straight forward would be sysfs write and away it runs, not so straight forward is tracking down the bit that is missing
[10:22] <ogra_> well, i guess i can add a hack that removes both packages before building the initrd
[10:22] <day> lilstevie: day, so spend some time following it being enabled in android :p -> ur talking about the reengineering process?
[10:22] <ogra_> its just ugly :(
[10:22] <xnox> ogra_: can you work around it in the seeds, or shall I demote lvm2 to suggests?
[10:22] <xnox> ogra_: can you not blacklist it?
[10:22] <lilstevie> day, of course, how else would you expect to do it
[10:23] <xnox> ogra_: to be honest it's wrong to install those, simply to get oem-config.
[10:23] <ogra_> we dont have any blacklist, the only way i coudl do that would be in the seeds ... but thats arch and not subarch specific
[10:23] <ogra_> which would mean no lvm2 seeded on arm servers either
[10:23] <day> lilstevie: i dont know, maybe take a look on the datasheet? but i guess thats no available :P
[10:23] <ogra_> you dont really want that :)
[10:23] <xnox> ogra_: split ubiquity into ubiquity & ubiquity-partman-deps ?
[10:24] <lilstevie> ogra_, which would also hurt me cause I use lvm2 on the tf201
[10:24] <ogra_> hmm, that might work
[10:24] <lilstevie> day, I'm saying YOU do it :p I'm not going to, not high enough of a priority
[10:24] <ogra_> we really want to keep lvm on systems that run a partitioner
[10:24] <xnox> ogra_: but then we would have to carefully install ubiquity-partman-deps on the images that have installer.
[10:25] <lilstevie> xnox, at the moment we are seeding with oem-config but use lvm
[10:25] <xnox> horum.
[10:25] <ogra_> yeah, i should probably just add some apt-get purge code to the build scripts
[10:25] <day> lilstevie: if i had a clue of driver programming under linux i would. :P
[10:26] <xnox> ogra_: well we can add more black magic to the initramfs hook in the lvm2 package to not copy itself as eagerly as it currently does.
[10:26] <lilstevie> xnox, but adding lvm to the seeds I guess isn't a problem
[10:26]  * ogra_ prays that his abootimg quoting is now right 
[10:26] <ogra_> xnox, i'm not sure the lvm2 bits are the biggest ones, there is also kpartx
[10:28] <xnox> ogra_: wait you _do_ use lvm2 on nexus7 images?
[10:28] <xnox> lilstevie: ^
[10:28] <ogra_> xnox, no
[10:28] <ogra_> lilstevie talks about the asus transformer
[10:28] <xnox> ah.... =)
[10:28] <lilstevie> xnox, not nexus 7 tf201, but we have been following the same method to generate images
[10:29] <ogra_> hmm, i wonder how much dropping parted from the initrd would gain me
[10:29] <ogra_> we only need it on the ac100, the ac100-tarball-installer could just not pull it in if we build for xenus
[10:29] <ogra_> *nexus
[10:30] <ptl> I modified a setting in nvidia-tegra x11.org template and now it does not start X. How can I recover?
[10:31] <ptl> in Ubuntu Nexus7
[10:31] <ogra_> did you install openssh-server ?
[10:31] <ptl> yes
[10:31] <ogra_> so you can get in via the network
[10:31] <ptl> how? it needs the graphical login to start, isn't it?
[10:32] <ogra_> no
[10:32] <ogra_> you should be able to just ssh in
[10:32] <ptl> er... no it doesn't :P
[10:32] <ptl> sorry
[10:33] <ptl> if I install gpsd on Ubuntu Nexus 7 and some gps program, will I be able to use it as a GPS?
[10:34] <ogra_> dunno, try it (and document what you did to make it work once you have it working)
[10:35] <ptl> k thx :)
[11:28] <ogra_> oh, wow, the HDMI multi monitor mode of the chromebook is impressive, unity automatically picks it up and adds four new workspaces
[11:33] <lilstevie> nice
[11:38] <janimo> ptl, Android uses some binary libraries on the Nexus7 for GPS. So you may not be successful unless you figure out how to use them, or find free alternatives
[11:38] <janimo> but there needs to be some hw specific support somewhere
[11:39] <janimo> I don't know anything about GPS though, besides what i wrote above :)
[13:29] <ptl> anyone knows a good CuBox kernel that has the device mapper compiled in?
[13:30] <ptl> janimo: oh, thanks for the info :-/ I thought GPS was something more open than that though
[13:30] <ptl> I would expect that from, say, GPRS stack
[13:31] <janimo> ptl, https://developers.google.com/android/nexus/drivers#grouperjop40c has GPS blobs in the same zip as wifi and BT
[13:32] <janimo> that said it may not be hard to integrate with gpsd I have no idea how the GPS stack looks like :)
[13:32] <ptl> <- tired by all this closed-minded approach of hardware manufacturers
[13:32] <janimo> cyphermox in ubuntu-devel has the task this cycle to look into GPS among other things
[13:38]  * janimo wonders whether to ust include most nexus7 blobs in the raring nexus firmware package to ease tinkering
[13:38] <ogra-cb> ++ if legal allows
[13:41] <ptl> what's '-cb', ogra?
[13:42] <ogra-cb> chromebook
[13:43] <ptl> dang, I thought it would be CuBox :D
[13:43] <ogra-cb> nah, i dont touch cortex-a8 anymore
[13:44] <ptl> it is cortex a9, isn't it?M
[13:45] <ogra-cb> ah, might be
[14:18] <lilstevie> isn't the CuBox a Marvell Armada510
[14:23] <ptl> lilstevie: yes
[14:51] <ogra-cb> [ ]   livecd.ubuntu-nexus7.bootimg                         20-Nov-2012 11:24 8.0M
[14:51] <ogra-cb> [ ]   livecd.ubuntu-nexus7.bootimg-nexus7                  20-Nov-2012 11:24 8.0M
[14:51] <ogra-cb> [ ]   livecd.ubuntu-nexus7.img                             20-Nov-2012 11:24 757M
[14:51] <ogra-cb> [ ]   livecd.ubuntu-nexus7.img-nexus7                      20-Nov-2012 11:24 757M
[14:51] <ogra-cb> \o/
[14:52] <dholbach> yoohoo
[14:52] <ogra-cb> still to big, but at least it should boot now
[14:54] <Tassadar> wau
[14:55] <Tassadar> well, what exactly livecd means, i mean, is it normal image or..?
[14:55] <ogra-cb> thats the raring (13.04) image i'm working on
[14:58] <Tassadar> by the way, is abootimg part of this whole ubuntu-supports-android-devices thing?
[14:58] <ogra-cb> well, we currently use it to creatte or modify boot image parameters
[14:59] <Tassadar> it does not fill the id[] part of the boot image's header
[14:59] <ogra-cb> is that important for anything ?
[14:59] <ogra-cb> i havent seen probs caused by rgar neither on the ac100 nor on the nexus7
[15:00] <Tassadar> not really, just explaining why I care
[15:00] <ogra-cb> s/rgar/that/
[15:01] <lilstevie> Tassadar, little more explanation please :)
[15:02] <lilstevie> doesn't cause issues with tf101/tf201 either fwiw
[15:03] <Tassadar> Well, I use the id array to distinguish boot images when multi-booting, I simply noticed that default ubuntu's boot.img has all 0's, which is not correct
[15:04] <Tassadar> the id is important only so that you can say that boot images are different only by reading header
[15:04] <Tassadar> and I thought tha abootimg was created as part of ubuntu
[15:07] <ogra-cb> t was created as part of the ac100 netbook being enabled for linux
[15:07] <ogra-cb> ubuntu was simply the first ditro to run on it :)
[15:08] <ogra-cb> and the tool is helpful enough to be used with all existing android bootimages
[15:09] <ogra-cb> i assume there is a way to set the id field with something
[15:09] <Tassadar> no, not really
[15:09] <Tassadar> I'm gonna go find source repository and maybe send a patch or something
[15:10] <ogra-cb> abootimg -u <bootimg> -c "id=foo"
[15:10] <ogra-cb> something like that doesnt work ?
[15:10] <Tassadar> I searched the code, and it just sets it to zero I think, I'll check again
[15:12] <ogra-cb> well, i'm pretty sure gilles is open to patches that fix this
[15:15] <Tassadar> yeah, just calloc(), which sets everything to 0, and then it is not changed anywhere
[15:15] <Tassadar> hmm, gitorious can't do forks, can it? Oh well
[15:16] <Tassadar> Ah, it just calls it "clone", okay
[15:53] <ogra-cb> sigh, if i only had named the image right
[16:03] <vanhoof> ogra-cb: happy to test as well if you'd like :)
[16:04] <ogra-cb> nothing to test yet, but i will shout
[16:04] <vanhoof> ogra-cb: cool
[16:05] <vanhoof> ogra-cb: did an upgrade friday to R with only a few issues :)
[16:05] <ogra-cb> debian-cd doesnt handle it if its called .img, i had to rename it .... which means a change in livecd-rootfs ... uploading it ... waiting for the publisher to promote it, waiting for the local builder mirror to pick it up and then a 90min build
[16:05] <ogra-cb> so expect something from my next attempt in 3h or so :)
[16:31] <vanhoof> ogra-cb: asked that reporter for more info on where UDA is actually mapped to
[16:31] <vanhoof> ogra-cb: https://bugs.launchpad.net/ubuntu-nexus7/+bug/1079729/comments/28
[16:31] <ubot2> Launchpad bug 1079729 in ubuntu-nexus7 "Ubuntu uninstallable on 32GB 3G Nexus 7" [High,Invalid]
[16:32] <vanhoof> ogra-cb: quite odd, even though his value is slightly less than mine here, should still fit within the 27gb boundry
[16:32] <ogra-cb> vanhoof, yeah, i was wanting to do that but then my build finished and distracted me
[16:32] <vanhoof> ogra-cb: one thing I noticed after forcing the OTA update to 4.2, is I now have a /sdcard/0/
[16:32] <vanhoof> but im not sure how that would impact things
[16:33] <ogra-cb> well, it will unlikely repartition the device
[16:33] <ogra-cb> but there will likely be devices with different MMCs
[16:33] <Tassadar> 0/ is just a folder
[16:33] <ogra-cb> which will require different partitioning
[16:34] <vanhoof> Tassadar: yeah just the only thing I noticed that is different after moving to 4.2 from 4.1.2, not sure its related at all
[16:34] <ogra-cb> especially since android solely works by name the device can be anything
[16:35] <Tassadar> hmm, that means I should use only partition names too
[16:35]  * Tassadar takes a note
[16:35] <ogra-cb> no, you want labels
[16:36] <Tassadar> I mean the "/dev/block/platform/sdhci-tegra.3/by-name/APP"-like paths
[16:37] <Tassadar> so yeah, labels, wrong term, sorry)
[16:47] <hrw> Tassadar: android 4.2 added multiuser handling
[16:47] <hrw> Tassadar: that's why you have /0/ in many places
[16:47] <hrw> Tassadar: check /data/ as well
[16:49] <Tassadar> yeah, I've noticed
[16:51] <hrw> my archos tablet will probably break before 4.2 will be available for it
[16:51] <prpplague> hehe
[16:52] <hrw> omap4430 suxx
[16:52] <Tassadar> well, I've downgraded back to 4.1 anyway
[16:52] <Tassadar> they removed tablet UI, and the whole system does not feel as snappy as before
[16:52] <Tassadar> :/
[16:57] <hrw> I will think 3 times before buying next tablet. 1st 'which one' 2,3 'are you mad?' ;D
[17:05] <vanhoof> ogra-cb: well there we go
[17:05] <vanhoof> lrwxrwxrwx root root 2012-11-20 13:48 UDA -> /dev/block/mmcblk0p10
[17:05] <ogra-cb> heh
[17:05] <ogra-cb> as i thought
[17:07] <ogra-cb> thats pretty bad
[17:07] <ogra-cb> it will add one additional reboot to the install process
[17:08] <ogra-cb> hmm
[17:08] <Tassadar> chm
[17:10] <vanhoof> ogra-cb: yup, RDO was added, which bumped UDA to p10
[17:11] <Tassadar> it is the 3g N7?
[17:11] <Tassadar> *is it...ya know
[17:11] <ogra-cb> so i think we need to go with UUIDs
[17:13] <vanhoof> Tassadar: yup
[17:13] <ogra-cb> *if* the fastboot ext4 allows us to update it at least
[17:14] <Tassadar> at least the boot image is the same
[17:14] <ogra-cb> yes, thats the issue, while we can use that for initial booting, the uuid should be unique
[17:15] <ogra-cb> so we need to update it
[17:16] <Tassadar> can't you use the "/dev/block/platform/sdhci-tegra.3/by-name/APP" path?
[17:18] <ogra-cb> no
[17:18] <ogra-cb> its non existent without android kernel
[17:19] <ogra-cb> ubuntu@nexus7-roccos:~$ sudo blkid /dev/mmcblk0p9
[17:19] <ogra-cb> /dev/mmcblk0p9: UUID="fc97cb4c-1167-4367-8fe8-68f7cec543ab" TYPE="ext4"
[17:19] <ogra-cb> ubuntu@nexus7-roccos:~$ sudo tune2fs -U $(uuidgen) /dev/mmcblk0p9
[17:19] <ogra-cb> tune2fs 1.42.5 (29-Jul-2012)
[17:19] <ogra-cb> ubuntu@nexus7-roccos:~$
[17:20] <ogra-cb> ubuntu@nexus7-roccos:~$ sudo blkid /dev/mmcblk0p9
[17:20] <ogra-cb> /dev/mmcblk0p9: UUID="3be1ed4a-5de5-460d-b5ff-2d3174db55cc" TYPE="ext4"
[17:20] <ogra-cb> ah, well, seems to work
[17:20] <ogra-cb> lets see if the fs is still working after a reboot
[17:20] <ogra-cb> usually it starts eating itself as soon as i used any filesystem tools on it
[17:21] <Tassadar> oh, I see, ueventd creates that path
[17:21] <ogra-cb> yay, that works fine
[17:26] <ogra-cb> so we just need to store the image UUID somewhere the initrd can read it
[17:26] <ogra-cb> on first boot
[17:27] <ogra-cb> and after extracting the tarball we bump to a new uuid and set a proper root= cmdline pointing to it
[17:29] <ogra-cb> but well, first let me get images at all
[17:29] <ogra-cb> vanhoof, you can turn the bug into an ac100-tarball-installer one
[17:30] <ogra-cb> thats the place where i'll fis it for raring
[17:30] <ogra-cb> *fix
[18:16] <Tassadar> ogra-cb: hmm, you think it's okay to find /data by parsing /proc/partitions and looking for the biggest one?
[18:16] <ogra-cb> huh ?
[18:17] <ogra-cb> why would i search for the biggest partition ?
[18:17] <Tassadar> I mean, when I do the multi-boot, I need /data partition, and I can't really use UUID
[18:17] <ogra-cb> i just want to find the one the tarball lives in
[18:19] <ogra-cb> fastboot flashes to userdata, it knows what the biggest one is etc
[18:19] <ogra-cb> the image we flash has (as every ext4 filesystem) a uuid
[18:19] <ogra-cb> so our installer bootimg will have that uuid in its root= arg
[18:20] <ogra-cb> to make the uuid actually unique we update the uuid on the fs and in the bootloader after untarring
[18:20] <ogra-cb> its not different to what we do now just that the uuid gets updated
[18:21] <ogra-cb> and that we dont depend on device names
[18:21] <Tassadar> yes, I am lookin for a way to find data partition during boot, which would work on both android and ubuntu, and all the Nexus models
[18:22] <RaYmAn> you could read the nvidia partition table and find the UDA partition number, then convert it to the GPT partition number :P
[18:22] <vanhoof> ogra-cb: yup
[18:22]  * ogra-cb will seriously stick to ubuntu defaults
[18:23] <ogra-cb> which means root=UUID=...
[18:23] <vanhoof> ogra-cb: will do, was just looking at tarball-installer and thinking about how to fix :D
[18:23] <Tassadar> okay, i will use the dumb "find biggest" method, since I can't think of a scenario in which it will fail :)
[18:30] <mfisch> cwayne: I'm going to try that gsettings switch for gksu in our defaults
[18:30] <mfisch> cwayne: but I Think people will need to reinstall to get the setting
[18:30] <cwayne> mfisch: reinstall that package?
[18:30] <cwayne> or reinstall the system
[18:31] <mfisch> cwayne: system, because it's a settings override
[18:31] <mfisch> creating a new user also works, that's how I'll test it
[18:31] <cwayne> mfisch: ack
[18:33] <mfisch> oh this is gconf, not gsettings
[18:34] <vanhoof> ogra-cb: fixed up that bug and added a brief description
[18:34] <ogra-cb> great
[18:35] <vanhoof> ogra-cb: lmk if that works for you
[18:36] <ogra-cb> sounds good, yep
[18:58] <ogra-cb> vanhoof, for the tarball-installer in case you want to fix it for quantal, pull abootimg into the initrd using the hook script, detect if you are on a 3G model on boot, in that case use abootimg to update the cmdline in mmcblk0p2 and reboot
[19:00] <vanhoof> ogra-cb: any sane way to detect, short of polling the partitions, assuming we only have bb at that point right?
[19:01] <ogra-cb> you have proc ;)
[19:01] <vanhoof> fair enough :)
[19:01] <ogra-cb> and dev indeed
[19:02] <ogra-cb> what Tassadar said above should work for a hack
[19:02] <ogra-cb> cat /proc/partitions .... sort ... head -1
[19:02] <ogra-cb> or some such
[19:03] <ogra-cb> (likely some more processing needed)
[19:11] <vanhoof> ogra-cb: *curses*
[19:11] <vanhoof> dd
[19:11] <vanhoof> [...]
[19:11] <vanhoof> <no label>
[19:11] <vanhoof> [...]
[19:11] <vanhoof> ;)
[19:15] <ogra-cb> vanhoof, cat /proc/partitions| grep $(cat /proc/partitions |grep mmcblk0p|awk '{print $3}'|sort -gr|head -1)
[19:15] <ogra-cb> thats good enough for a hack
[19:15] <vanhoof> ogra-cb: right, I was attempting to be clever w/ dd to parse any label or evidence of UDA :)
[19:16] <Tassadar> and it indeed works
[19:16] <RaYmAn> vanhoof: did you look at uhm, /dev/block/by-name/ or similar?
[19:16] <ogra-cb> you can likely somehow get it out of the GPT
[19:16] <Tassadar> well, the 50-line C function equivalent to that one bash line works :D
[19:19] <vanhoof> RaYmAn: dd'ing off of the raw device itself (p9) and inspecting w/ strings to see what I can find
[19:19] <vanhoof> RaYmAn: more so curious if anything :)
[19:20] <Tassadar> RaYmAn: these do not exist when using ubuntu kernel
[19:20] <ogra-cb> grep $(grep mmcblk0p /proc/partitions |awk '{print $3}'|sort -gr|head -1) /proc/partitions
[19:21] <ogra-cb> whorter and less cat'ing :)
[19:21] <ogra-cb> *shorter
[19:22] <RaYmAn> Tassadar: hmm..well, android kernel must be getting it from somewhere.
[19:22] <ogra-cb> from the GPT i guess
[19:22] <Tassadar> it certainly must, but I don't wanna change ubuntu's kernel
[19:22] <Tassadar> wait, I think I know..
[19:23] <Tassadar> hm, no I dont
[19:24] <RaYmAn> those partitions names are a bit of a mess across asus transformer devices. Some of them have wrong names by default , which may or may not get fixed during random OTA flashes. So don't expect that kind of detection to work outside of N7
[19:24] <Tassadar> I thought I saw something like that in ueventd.*.rc files in boot image, but it must have been something else
[19:50] <ogra-cb> hmpf
[19:50] <ogra-cb> http://cdimage.ubuntu.com/daily-preinstalled/20121120.3/
[19:51] <ogra-cb> but the bootimg file is missing :/
[19:53] <ogra-cb> thats something i'll sort oout tomorrow morning though
[23:25] <vanhoof> ogra-cb_: trimmed that down significantly, now checking out what I can do w/ abootimg :)
[23:27] <vanhoof> $(grep mmcblk0p /proc/partitions | sort -gr -k3 | awk 'NR == 1 {print $4}')
[23:27] <vanhoof> now if I only had a device to test ;)
[23:40] <ogra-cb_> abootimg -i /dev/mmcblk0p2 |grep cmdline
[23:40] <ogra-cb_> that'll give you the current commandline
[23:40] <ogra-cb_> abootimg -u /dev/mmcblk0p2 -c "cmdline=my shiny new commandline"
[23:41] <ogra-cb_> that will set the new one
[23:41] <ogra-cb_> dont use /proc/cmdline here, it has a ton of hardcoded bootloader things in it that you dont want in the bootimg
[23:44] <ogra-cb_> anyway, eod ...
[23:45] <ptl> anyone has the same experience?
[23:45] <ptl> hi, I have just tried a few sound programs in ubuntu on nexus7 and none worked
[23:47] <ptl> even gst123