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