[04:07] <isaias> how do i get my nexus 7 back to normal?
[04:18] <suihkulokki> is there any plan to put strace 4.7 to raring
[09:26] <sspiff> hi, can I find a list of supported platforms for Ubuntu's ARM work?
[09:26] <sspiff> I'm wondering if it would work, with graphics acceleration, on an OMAP 4470 platform
[09:27] <ogra_> it definitely does on 4460, not sure about 4470
[09:28] <ogra_> the pandaboard was for years our reference platform
[09:29]  * infinity has never even seen a 4470...
[09:30] <infinity> Looks like the big difference is a PVR SGX544 instead of a SGX540.
[09:30] <infinity> So, entirely possible that the PVR binary blobs in precise wouldn't know about the new revision.
[09:33] <ogra_> yeah
[09:33] <ogra_> and since TI put OMAP to death for mobile we likely wont get any updated drivers anymore
[09:39] <sspiff> infinity, ogra_: I'm asking specifically because I'm looking for a cheap but usable platform to run ubuntu on, and I came across the Archos 101 XS
[09:40] <sspiff> which seems like a nice match, except for the low RAM. I was only worrying about the SGX544
[09:40] <infinity> sspiff: Well, I honestly can't say one way or the other.  The last SoC *I* tested on was a 4460, but someone may have played with a 4470.
[09:40] <sspiff> do the binary drivers for Linux and Android differ greatly?
[09:40] <ogra_> well, if you would be fine moving to the ubuntu phablet edition (which HW wide depends on a minimal android layer) you should be fine with that HW
[09:40] <infinity> sspiff: They're completely different, yes.
[09:41] <ogra_> if you expect to fully natively run ubuntu on it (xorg, ubuntu kernel etc) i would go with a nexus device
[09:41] <sspiff> infinity: hence the ubuntu phablet architecture leveraging the Android platform
[09:41] <ogra_> right
[09:41] <sspiff> ogra_: I considered that, but they're considerable more expensive and no decent good keyboard docks
[09:41] <infinity> sspiff: The phablet/Android madness is more of a stopgap than an end goal. :)
[09:41] <infinity> But it works for enablemnet on devices where we'll never see native drivers.
[09:41] <infinity> For some value of "works".
[09:41] <ogra_> well, the android layer will stay
[09:42] <ogra_> it wil; shrink and bits will move into the distro, but it wont go away
[09:42] <infinity> Erm.  Define "stay".
[09:42] <infinity> If we get native drivers and have no need for bionic, we have no need for said layer.
[09:42] <ogra_> infinity, the higher layer is designed to use libhybris and friend and to rely on HAL
[09:43] <infinity> See above.
[09:43] <infinity> Nothing depends on hybris, except that some things depend on bionic, thus we need hybris.
[09:43] <ogra_> well, i doubt we want to go back to "we only support one device"
[09:43] <infinity> Kill the bits that need bionic (binary blobs), and we don't need any of it.
[09:43] <ogra_> while we already support over 30 after a week
[09:43] <ogra_> with the new image
[09:43] <infinity> The option for the Android layer is always there.
[09:43] <infinity> The end goal for a branded device isn't that, though.
[09:43] <infinity> Just sayin'.
[09:44] <ogra_> android makes porting extremely easy ...
[09:44]  * ogra_ produced that http://people.canonical.com/~ogra/phablet/i9100/ withing a few hours yesterday
[09:44] <ogra_> *within
[09:44] <ogra_> and i have *zero* android experience
[09:45] <ogra_> i guess the layer might go away for devices we will preinstall on, but not for the unwashed masses
[09:45] <infinity> I'm not sure I call it "porting", when you're just sucking in device support that's already there.
[09:45] <ogra_> (if thats even possible with that design, the userspace apps make a lot of use of android bits)
[09:46] <infinity> Erm, they do?
[09:46] <ogra_> true, its not actual porting :)
[09:46] <infinity> The system is glibc-based.
[09:46] <ogra_> but needs the underlying API to talk to the HW
[09:46] <infinity> That goes right back to the binary blobs thing.
[09:46] <infinity> But yeah.
[09:46] <ogra_> we dont have alsa, there is vold, no graphics stack etc
[09:46] <infinity> We'll see how it pans out.
[09:47] <infinity> You're right that for mass porting to unsupported devices, we'll likely keep the hybris/android solution indefinitely.
[09:47] <ogra_> i.e. my image above has no wifi because samsung decided to have a dalvik based tool to bring up the driver
[09:47] <infinity> You know, until we replace Android as the #1 phone/tablet OS.
[09:47] <infinity> In 2023.
[09:47] <ogra_> so i end up without wlan0 on the device and there is no way from userspace to activate it
[09:48] <ogra_> i will need to hack something together on the android side for it
[09:49] <ogra_> the longer that "interim" situation persists the harder it will get to get rid of the android side, community is actively contributing bits that will closer tie us into that
[09:50] <sspiff> infinity: I understand the fact that it's a stopgap and that it's needed for easy device compatibility
[09:52] <sspiff> regardless, I'm not in the market for having to create a device branch for an ubuntu phablet, I'm looking for a minimal effort to get an ultramobile notebook-tablet hybrid experience
[09:52] <sspiff> if I'm going to have to hack support for the device, I know I'll never get around to it, to many hobby projects queuing in the backlog :)
[09:53] <ogra_> well, we currently support the nexus7 natively
[09:54] <sspiff> if the 4470 isn't going to work, a nexus solution would give me an inferior keyboard experience and with a decent dock etc the price of a nexus 10 becomes high enough to even consider Intel Core i3 solutions, which have good open source driver support
[09:54] <ogra_> and the panddaboard for desktop installs, the the future here is blurry .... i would ratrher expect that to die due to lack of drivers
[09:54] <sspiff> nexus7 is really to small for my needs, I'm looking for 10"
[09:54] <ogra_> well, we can onlye easily get our hands onto the tegra drivers
[09:54] <sspiff> yeah I assume the panda will go the way of the dodo soon, it's been removed from the AOSP as well
[09:55] <sspiff> ogra_: open source tegra drivers? or binary tegra drivers for Linux for a specific distro?
[09:55] <ogra_> so if you want Xorg, tegra HW is your best bet
[09:55] <ogra_> binary indeed
[09:55] <sspiff> I thought tegra/nvidia were completely unsupportive?
[09:55] <ogra_> GLES isnt well suppported in the open ones
[09:55] <sspiff> uhu, I really need GLES :P
[09:56] <ogra_> it might get there (if you belive nvidias marketing)
[09:56] <ogra_> but surely isnt yet
[09:56] <sspiff> I do some GLES coding, and the main goal of the device I'm looking for is a tablet testing environment, and a way to do some light coding/compiling/... on the train/plane/somewhere else where my 15" notebook isn't an option
[09:57] <sspiff> experience learns me to never expect support post-launch
[09:57] <sspiff> SoC obsolete so fast that you really want on-launch support
[09:57] <ogra_> well, i know for sure that nvidia works on an update for the drriver for the next Xorg ABI bump
[09:58] <ogra_> so these devices should be safe for a little while still (if you find an unlockable one like the nexus line)
[09:58] <sspiff> uhu
[09:58] <sspiff> the Transformer TF300 would be a Tegra3 based option, but not sure if it's unlocked
[09:58]  * ogra_ needs to give the cat her insuline shot, brb
[09:58] <sspiff> huh, I didn't know they did that for cats
[10:05] <ogra_> re
[10:06] <ogra_> yeah, they luckily do ...
[10:45] <ogra_> infinity, one for you :) https://plus.google.com/112266164281670850856/posts/RuPVvyrPBtU
[13:27] <Zero_Chaos> So, can anyone tell me how ubuntu makes their rootfs.img?
[13:28] <ogra_> we use live-build with some slight changes that are hidden in the livecd-rootfs source package
[14:35] <Zero_Chaos> ogra_: do you know if it is possible to make a rootfs.img from a nexus 7 tablet? basically I'm trying to take a functional modified tablet and copy it to another.
[14:36] <ogra_> zou can either just grab the nexus7 one and modify the tarball inside or start from scratch using an ubuntu-core tarball
[14:39] <Zero_Chaos> to be honest, I have a fully customized device now that I want to copy, I don't want to start over
[14:39] <tassadar_> Zero_Chaos: nandroid backup in recovery should be enough in fact, if you can/want use that
[14:40] <Zero_Chaos> tassadar_: is that a custom recovery or the stock android one? forgive me I'm new ;-)
[14:41] <tassadar_> custom recovery, it basically does .tar.gz from whole /data partition
[14:42] <Zero_Chaos> tassadar_: anything that does *everything*? I have a slightly custom android that has a custom ubuntu chroot in /data/local/ubuntu so I really wanted to grab all of rootfs
[14:43] <tassadar_> well, what do you consider "all of rootfs"?
[14:43] <ogra_> if you have a custom chroot already, just apt-get what you want
[14:43] <Zero_Chaos> tassadar_: /
[14:43] <Zero_Chaos> tassadar_: minus the obvious /dev /proc and /sys
[14:44] <tassadar_> uh
[14:44] <Zero_Chaos> that is "rootfs" afterall
[14:44] <tassadar_> data partition is / for ubuntu
[14:44] <Zero_Chaos> tassadar_: it's android with an ubuntu chroot right now
[14:44] <Zero_Chaos> but I know the full ubuntu install has a real nice rootfs that is easy to flash, just didn't know if I could make one from a running device easily
[14:45] <Zero_Chaos> looks like the answer is "not easily"
[14:45] <tassadar_> yeah
[14:46] <tassadar_> damn you, school wifi network -.-
[14:47] <Zero_Chaos> school sucks
[14:49] <tassadar_> yeah, and I have to go now, sorry, bye
[14:51] <Zero_Chaos> tassadar_: thanks for your help
[15:02] <micahg> Could someone please tell me if this look likes cosmic rays: https://launchpadlibrarian.net/132280468/buildlog_ubuntu-raring-armhf.octave_3.6.4-1_FAILEDTOBUILD.txt.gz
[15:03] <Zero_Chaos> I don't think I'd blame cosmic rays no matter what that log shows
[15:03] <Zero_Chaos> so no, it's not cosmic rays
[15:04] <ogra_> micahg, give it back ... if it doesnt fail the same way its cosmic rays :)
[15:04] <Zero_Chaos> ogra_: please don't tell people that, most of them are dumb enough to believe you...
[15:05] <ogra_> ??
[15:05] <Zero_Chaos> ogra_: it's not cosmic rays
[15:05] <Zero_Chaos> ogra_: thinking that is just embarassing
[15:05] <Zero_Chaos> ogra_: we aren't in space, we don't get enough random space radiation to have such issues down here
[15:05] <ogra_> well, it could be humidity in the datacenter ... or a fly sitting on a chip and shortening two contacts
[15:06] <Zero_Chaos> ogra_: hardware failure on the other hand is a very common issue.
[15:06] <micahg> Zero_Chaos: being that the build machines are in a unique case, we refer to cosmic rays as random failures to due HW env
[15:06] <Zero_Chaos> ogra_: it could be aliens with mind control, but hardware failure is a bit more common don't you think?
[15:06] <ogra_> it could be cosmic ray induced HW failure ;)
[15:07] <Zero_Chaos> micahg: if you want to use an insane case to speak about a sane one that is your choice, but I'm still going to watch and assume you are stupid.
[15:07]  * micahg is really feeling the love in here
[15:07]  * ogra_ hugs micahg 
[15:07]  * micahg hugs ogra_ back
[15:07]  * micahg should probably just break down and create a cross-build chroot
[15:07] <Zero_Chaos> micahg: I know a lot of people that think "cosmic rays" means "cosmic rays". using stupid terms like that causes more misunderstanding in an already misunderstood field.
[15:08] <ogra_> that wont get you far on the buildd though
[15:08] <ogra_> Zero_Chaos, its a commonly used term in here ... and please stop calling people stupid in ubuntu channels
[15:08] <micahg> ogra_: well, it should tell me if there's an inherent failure in the build, it certainly won't catch all cases though
[15:08] <ogra_> yeah
[15:09] <ogra_> do you know if thats a virtualized or a devirtualized builder ?
[15:09] <micahg> ogra_: using the cross libc, it wouldn't tell me if there were an assembler failure though, right?
[15:09] <ogra_> could well be a qemu issue
[15:09] <Zero_Chaos> ogra_: I didn't call anyone stupid, I said I would sit back and assume he was because he is using a term that deliberately breed misunderstanding.
[15:09] <micahg> ogra_: devirt (archive)
[15:09] <ogra_> yeah
[15:09] <ogra_> oh, ok
[15:10]  * micahg will give back then as he doesn't have the proper hardware to do a test (and the buildds are relatively free)
[16:50] <achiang> Zero_Chaos: in fact, computers on earth *are* affected by cosmic rays. in early days of one of the supercomputers i worked on, we had to install a large tank of water above the server room to absorb them, to prevent RAM corruption issues caused by random bit flipping due to cosmic rays
[16:50] <achiang> Zero_Chaos: later on, we improved the shielding on the DIMMs
[16:52] <achiang> Zero_Chaos: and of course, due to wave/particle duality at the quantum levels, i'd say that it is quite reasonable to use "ray" and "particle" interchangably in this context
[17:25] <Zero_Chaos> achiang: is this 1962?
[17:26] <achiang> Zero_Chaos: is that relevant?
[17:26] <Zero_Chaos> achiang: yes, because "computer's are affect by cosmic rays" is very different from "computer's were affected by cosmic rays 30 years ago before they were properly shielded"
[17:27] <achiang> Zero_Chaos: this was 2002.
[17:28] <achiang> Zero_Chaos: so if you could stop calling people stupid, that would be great. thanks.
[17:28] <Zero_Chaos> achiang: during one of the longest solar minimums in history? I'm... shocked may be the word
[17:29] <Zero_Chaos> achiang: and again, picking the single least likely scenario is not good practice, and it perpetuates confusion in the industry, and that is stupid, which is what I said.
[17:30] <ogra_> can we drop thatr off-topic now ?
[17:30] <Zero_Chaos> achiang: when gcc compile fails over and over, in a different place, I don't say it's cosmic rays, I say it's ram.  And you know what, wrapping the computer in 10 ft of tin foil can't fix what new ram can
[17:32] <ogra_> there is no computer to wrap ... its all dev boards without any casing
[17:32] <ogra_> but pretty please stop this topic now
[17:35] <Zero_Chaos> ogra_: it was my intent to say that using the term "cosmic rays" for seemingly random failures is confusing for new users and should be avoided.  I'm sorry this point confused so many people in here.
[17:56] <ogra_> https://lists.ubuntu.com/archives/ubuntu-devel/2013-March/036776.html
[17:58] <Zero_Chaos> interesting
[19:05]  * micahg shows Zero_Chaos the retry build has made it past where it was: https://launchpad.net/ubuntu/+source/octave/3.6.4-1/+build/4325207, hooray for Cosmic Rays :)
[19:06] <Zero_Chaos> micahg: yeah, random hardware failure does the same thing all the time. especially heat and RAM issues
[19:06] <Zero_Chaos> micahg: but hey, you are welcome to think whatever you like, I realized long ago that if you don't listen I shouldn't care either
[19:07] <micahg> if you want people to listen to you, it doesn't hury to listen first ;)
[19:07] <micahg> s/hury/hurt/
[19:08] <Zero_Chaos> micahg: I did listen. you think cosmic rays messed up your build. I think it's just as likely that a ghost did it.
[19:08] <micahg> [09:06] <micahg> Zero_Chaos: being that the build machines are in a unique case, we refer to cosmic rays as random failures to due HW env
[19:09] <Zero_Chaos> micahg: yeah I read that, and I was trying to say that people reading that assume you mean real cosmic rays not using it as a euphemism for "something failed and I don't know what"
[19:10] <Zero_Chaos> micahg: thus, causing entropy and stupidity in the general populace
[19:10] <Zero_Chaos> micahg: and since like three people have "stood up to me" in the last hour to tell me how cosmic ray can actually affect building, I stand by my point.