[11:07] <mythos> hui... i got my pi today =)
[11:07] <mythos> and pandaboard es is on its way =)
[11:08] <ogra_> http://www.ebay.com/itm/Raspberry-Pi-Fedora-Operating-System-8GB-SD-Card-Expanded-/300705977609
[11:08] <ogra_> ;)
[14:52] <ogra_> http://donaldclarkplanb.blogspot.co.uk/2012/05/raspberry-pi-7-reasons-why-it-wont-work.html
[16:25] <rbasak> ogra_: ping
[16:26] <rbasak> ogra_: dannf found an issue with Debian's flash-kernel that breaks Ubuntu completely, AIUI. Do you have time to discuss it now?
[16:26] <rbasak> (as in today - I'll be about 20 mintues)
[16:26] <ogra_> rbasak, yeah, go ahead (will be my last action today too)
[16:27] <rbasak> dannf: over to you?
[16:27] <ogra_> i'm aware that f-k will likely need adjustments
[16:27] <ogra_> though we want to keep them as msall as possible
[16:27] <dannf> ogra_: just the linux-base package / linux-version bit
[16:27] <rbasak> Are you planning on uploading anyway even if we know it won't work?
[16:27] <ogra_> uploading ?
[16:27] <rbasak> Or do we want to get a fix in first?
[16:27] <ogra_> it was synced this morning (EU time)
[16:28] <rbasak> Ah
[16:28] <rbasak> So we have a regression and it currently won't work at all for any board?
[16:28] <ogra_> i will jump on it tomorrow (unless someone fancies to produce a patch tonight) and beat it in shape
[16:29] <rbasak> I'm concerned about your approach here. Aren't we supposed to be testing first to prevent regressions in the development release?
[16:29] <ogra_> the plan is to have at least omap and omap4 images ready for A1 so that means i have to touch it :)
[16:30] <ogra_> rbasak, that would have taken weeks, we're pre A1 which is exactly the time to introduce such changed and fix issues before the first milestone
[16:30] <ogra_> *changes
[16:30]  * dannf looks at lp:ubuntu/flash-kernel - and yeah, it depends on the linux-version tool from debian's linux-base package
[16:30] <ogra_> also it was discussed three times at three UDSes to do it that way
[16:30] <rbasak> ogra_: regressions in d-i for ARM blocks our work.
[16:31] <ogra_> thats why i warned you ahead of the change
[16:31] <dannf> luckily, that means it shouldn't be installable either (luckily for any bleeding edge users)
[16:31] <ogra_> right
[16:31] <rbasak> By a day, which didn't really give us any time to work around the issue or prepare a fix in advance
[16:31] <ogra_> images arent properly buildint anyway yet
[16:31] <ogra_> *building
[16:32] <ogra_> (due to buildd issues that were only fixed today too)
[16:32] <ogra_> in any case this surely wont happen again, but we had to make a hard cut for f-k
[16:33] <ogra_> since it was 80% hacks that simply werent portable to the new world order
[16:33] <ogra_> (we forked about 4 years ago and it wasnt updated since, since the hacks would have been broken heavily)
[16:34] <dannf> ogra_: one option is probably to discuss pulling in the linux-base package as well
[16:34] <dannf> debian has split that out of the linux-2.6 package
[16:34] <ogra_> right, I'll discuss that with the rest of foundations
[16:34] <dannf> but that probably needs to be coordinated w/ the kernel team give the perf wrapper it adds (or disable that wrapper)
[16:35] <ogra_> we have linux-tools that ships perf iirc
[16:35] <dannf> ogra_: i don't think anyone disagrees that rebasing on debian is the right approach; the "how" is biting us, but the "why" is pretty obvious
[16:35] <dannf> yeah, debian uses linux-base to chhoose the perf that's compatible w/ the current kernel abi
[16:36] <dannf> it doesn't build a perf, just directs to it
[16:36] <ogra_> linux-base should be installable according to the kernel team
[16:37] <dannf> ah - maybe i misesd that; lemme try
[16:37] <ogra_> as i said, i'll fix the issues tomorrow by A1 f-k should work fine
[16:37] <ogra_> (and seriously depending on image buolds even before the first milestone was rolled should be reconsidered in your policy)
[16:38] <rbasak> The trouble is that we can't work using precise, since that's fixed now
[16:38] <rbasak> eg. highbank needs to go in quantal first before SRU
[16:38] <rbasak> So we have to work on quantal
[16:38] <ogra_> that wont work for f-k
[16:39] <rbasak> Yeah f-k will need an old-style patch for precise
[16:39] <dannf> i see it on packages.ubuntu.com, but apt doesn't see it on my armhf/quantal bxo.. /me digs
[16:39] <ogra_> since they are completely different in both releases
[16:39] <ogra_> dannf, make sure to use armhf ;)
[16:39] <rbasak> I'm talking about process though - the general principle that we work on the dev release, and that we need netinst to work on the dev release.
[16:39] <ogra_> the kernel team doesnt build for el anymore
[16:40] <ogra_> rbasak, but it is pre-A1
[16:40] <ogra_> nobody expects images or the installer to work before that ... this is the only time where such changes can be made
[16:40] <rbasak> So essentially you're saying that the principle that the development release remains usable does not apply pre-A1?
[16:40] <dannf> ogra_: my only armel box is a armv5 running debian, so that's not a problem :)
[16:40] <ogra_> rbasak, installable
[16:41] <rbasak> OK, I think I understand your POV now, thanks.
[16:41] <ogra_> not usable ... using precise and upgrading should always work
[16:41] <dannf> mystery solved, linux-base is in universe
[16:41] <ogra_> installing should work after the first milestone (for the images that made it at least)
[16:41] <ogra_> dannf, ah, i'll care for the MIr and promotion then
[16:41] <dannf> ogra_: ack
[16:41] <ogra_> dannf, that should keep you safe for d-i then though
[16:42] <ogra_> i hope to have the worst bits solved before the weekend, the rest will happen during milestone freeze
[16:52] <ogra_> dannf, rbasak, one other thing with the new f-k ... it wont allow booting without initrd by design, is that an issue for you guys (i assume not, else we can change that)
[16:53] <dannf> ogra_: i don't *think* its a problem
[16:53] <ogra_> (essentially i would like to keep the ubuntu changes close to zero if possible though)
[16:53] <dannf> ogra_: +1
[16:53]  * dannf much prefers hacking on the redesigned version
[16:54] <ogra_> ++
[16:54] <rbasak> We're using an initrd everywhere so I think it's fine
[16:54] <rbasak> But isn't there a discussion on allowing initrd-less systems in ubuntu at some point? I never understood the motivation for this.
[16:54] <ogra_> yeah, i though so
[16:55] <ogra_> yes, i'm the driver behind that
[16:55] <rbasak> So how is that going to work with a flash-kernel that requires an initrd?:)
[16:55] <ogra_> and i want to make f-k work without initrd in the future, its just not top on my TODO (i would have moved it if you said its needed)
[16:55] <rbasak> I see, thanks
[16:56] <ogra_> the current initrdless ubuntu stuff is blocked on the kernel team anyway
[16:56] <rbasak> So while you're here, what's the motivation/need for initrdless ubuntu anyway? Is this documented anywhere?
[16:56] <ogra_> as long as the kernel doesnt learn about UUIDs its moot to move on
[16:56] <ogra_> rbasak, 10 second boot vs 30 sec on the panda (and likely other u-boot based arches)
[16:56] <dannf> faster boot maybe?
[16:57] <ogra_> right
[16:57] <rbasak> I see
[16:57] <rbasak> Wouldn't UUID knowledge end up in the early-userspace code anyway?
[16:57] <rbasak> The kernel doesn't truly support initrd-less any more anyway - just an embedded miniature initramfs now, right?
[16:57] <ogra_> well, it would have to be in the kernel itself for us
[16:57] <ogra_> up to precise initrdless booting still worked fine here
[16:58] <ogra_> i havent tried anything newer than 3.2 yet
[16:58] <ogra_> and i bet many embedded people would freak out if linus completely disabled initrdless
[16:58] <rbasak> OK but it's not been truly initrdless for a while. There's a shim. Knowledge of UUID could be inserted into that shim.
[16:59] <ogra_> right, that was one of the plans but needs to be done by the kernel team
[16:59] <rbasak> I see
[16:59] <ogra_> since that mini initrd lives inside the kernel binary
[16:59] <rbasak> Yep
[16:59] <rbasak> I'm with you now - thanks
[16:59] <ogra_> we'll see if it goes anywhere in the future
[17:00] <ogra_> ( i start doubting it ... though initrd less booting is on the request list for 5 years or more)
[17:00] <ogra_> (but so is booting in less than 10sec)
[19:48] <orated_> Hello! Is there any documentation/wiki where initrd.img  MLO  u-boot.img  uEnv.txt  uImage  uInitrd  zImage files are individually explained?
[19:51] <prpplague> orated_: same question was just asked on #beagle and i know you are over there
[19:52] <orated_> Oh, that is answered now! I remember same was questioned and I had exactly the same question yesterday  :)
[19:53] <orated_> Thanks, I'll catch up in that channel
[21:48] <dannf> ogra_, rbasak : https://code.launchpad.net/~dannf/flash-kernel/armadaxp/+merge/108066
[22:03] <dannf> ogra_: rbasak : whups, should be : https://code.launchpad.net/~dannf/flash-kernel/armadaxp/+merge/108070
[22:53] <janimo> lilstevie, thanks. Do you know a way to root a tf101g with ICS 4.0.3 on it? I found confusing instructions in the forum which do not seem to work (red-belly android on his back). Should the updater take any image called E101_SUPDATE?
[22:54] <lilstevie> that is old
[22:54] <lilstevie> like really old
[22:54] <lilstevie> um
[22:55] <lilstevie> there is a method that symlinks /data/tmp to /dev/block/mmcblk0p4 that should work
[22:55] <lilstevie> mmcblk0p4 being the staging partition