| === TRON is now known as TypoNAM | ||
| === NCommand1r is now known as NCommander | ||
| mythos | hui... i got my pi today =) | 11:07 |
|---|---|---|
| mythos | and pandaboard es is on its way =) | 11:07 |
| ogra_ | http://www.ebay.com/itm/Raspberry-Pi-Fedora-Operating-System-8GB-SD-Card-Expanded-/300705977609 | 11:08 |
| ogra_ | ;) | 11:08 |
| ogra_ | http://donaldclarkplanb.blogspot.co.uk/2012/05/raspberry-pi-7-reasons-why-it-wont-work.html | 14:52 |
| === TRON is now known as TypoNAM | ||
| rbasak | ogra_: ping | 16:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| ogra_ | i hope to have the worst bits solved before the weekend, the rest will happen during milestone freeze | 16:42 |
| 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:52 |
| 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:53 | |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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 | 16:59 |
| 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) | 17:00 |
| orated_ | Hello! Is there any documentation/wiki where initrd.img MLO u-boot.img uEnv.txt uImage uInitrd zImage files are individually explained? | 19:48 |
| prpplague | orated_: same question was just asked on #beagle and i know you are over there | 19:51 |
| orated_ | Oh, that is answered now! I remember same was questioned and I had exactly the same question yesterday :) | 19:52 |
| orated_ | Thanks, I'll catch up in that channel | 19:53 |
| dannf | ogra_, rbasak : https://code.launchpad.net/~dannf/flash-kernel/armadaxp/+merge/108066 | 21:48 |
| dannf | ogra_: rbasak : whups, should be : https://code.launchpad.net/~dannf/flash-kernel/armadaxp/+merge/108070 | 22:03 |
| 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:53 |
| lilstevie | that is old | 22:54 |
| lilstevie | like really old | 22:54 |
| lilstevie | um | 22:54 |
| lilstevie | there is a method that symlinks /data/tmp to /dev/block/mmcblk0p4 that should work | 22:55 |
| lilstevie | mmcblk0p4 being the staging partition | 22:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!