[01:03] LOL @ ubuntu on ARM!! [01:04] ... [01:04] That was constructive. === prpplague^2 is now known as prpplague [01:40] infinity: its the little things === asac_ is now known as asac [02:22] ericm|ubuntu, Good morning. Quintasan was trying to compile imx-libs against linux-headers-2.6.35-1001-linaro-lt-mx53_2.6.35-1001.1_armel.deb based on guidance from http://boundarydevices.com/blogs/building-gstreamer-plugins-under-ubuntu and ended up withhttp://paste.kde.org/86929/. Do you happen to know of more modern (or working) instructions? [05:05] persia, paulliu knows the detail - btw, can you let Quntasan send email to us, me and pualliu, thanks [05:08] I'll try to convince him. Thanks for the pointer. === Lopi is now known as Lopi|idle === fairuz_ is now known as fairuz === apachelogger is now known as rohansgoogle === rohansgoogle is now known as apachelogger [10:49] soo, seems we have images again [10:50] og? [10:50] tabcomp fail :p [10:50] and the oversizedness is caused by the fact that the images contain *all* langpacks [10:50] oh dear [10:50] so how does one go about getting a package in universe [10:50] say a kernel [10:51] you file a bug pointing to the package and then find a sponsor [10:51] ok, sounds easy enough [10:51] or you get it into debian ... [10:51] which is the preferred way [10:51] but might be hard in case of kernels [10:52] would be hard in the case of my tab kernel [10:52] in any case it would be better to have upload privileges [10:52] going through sponsoring with a kernel is painful [10:53] heh [10:53] at least for followup changes and fixes [10:53] yeah that is what I am not looking forward to, with the sponsor method that is [10:54] neither will your sponsor [10:55] uploading a 90M package for every change is annoying, finding sponsors for that will not be easy [10:55] long term i would suggest to earn upload privs [10:55] hm [10:56] or have someone with these privs in your team that maintains the arch [10:57] that sounds the hardest [10:57] Hi all, I have installed Ubuntu arm 11.04 on my beagleboard C3. The thing is usb devices attached to it works in the early stages of booting of the system. But when the booting finishes the usb devices stop working. Any ideas? [10:58] I don't know anyone with upload privs [11:01] ogra: the good news is though I am killing the last bug that affects basic usability since switching up to the new kernel [11:02] what version are you on now ? [11:02] 2.6.35.7 [11:02] oh, still ancient [11:03] yeah [11:03] but newer [11:04] Finding sponsors doesn't have to be that hard. I'm almost always willing to sponsor kernel uploads to universe, for example. [11:06] kunguz, Maybe bug #784474? [11:06] Launchpad bug 784474 in linux-ti-omap "usb enumeration fail on beagleboard" [Undecided,New] https://launchpad.net/bugs/784474 [11:07] ubot2: persia seems similar, thank you [11:07] kunguz: Error: I am only a bot, please don't think I'm intelligent :) [11:07] ubot2: but you are clever one :D [11:07] kunguz: Error: I am only a bot, please don't think I'm intelligent :) [11:08] kunguz, I'm not sure that's precisely the bug: it has a decent test scenario written up. If you can't replicate precisely that way, it's always safest to search a bit more for a bug you can precisely replicate, or file a new one. [11:08] * ogra ponders what to do with the images [11:08] What do you mean? [11:09] We should have enough space to include all langpacks on the 1 GB armel desktop [11:09] live images: [11:09] * /^language-pack-[^-]+$/ [armel] [11:09] * /^language-pack-gnome-[^-]+$/ [armel] [11:09] that ... [11:09] (paste from the live seed) [11:09] seems lool added that back when we still rolled live images [11:09] Let them be oversized for a bit more. In #ubuntu-devel there was some talk about sorting the internationalisation bit next week. [11:10] well [11:10] for live, yes [11:10] There's some reason to have *lots* of languages right now. [11:10] for preinstalled we likely need some extra code [11:10] and i dont really want 1G images [11:10] I suppose. [11:11] My suspicion is that the work on making sensible international images will end up reducing that substantially. [11:11] persia: even my galaxy tab 7" image? :) [11:11] lilstevie, *especially* your galaxy tab image. I would really like Ubuntu to support as many retail devices as we can. [11:11] ++ [11:12] But I'm not a kernel hacker, so all I can do is review other folks kernels, make sure they're packaged sanely, and help them get images from them. [11:12] :) [11:12] well I am within 24hours of a sane kernel [11:12] :) [11:12] For packaging, I'd recommend starting from either jcrigby's scripts or linux-n900 (derived from those)., depending on which makes you more comfortable. [11:13] persia, note that the hack above is armel only, no other arch ships all langpacks [11:13] I'm within 24 hours of my weekly "ignore IRC traffic for 20-30 hours" time, but I'd be happy to upload later in the weekend. [11:13] tbh I will need a bit of help with the packaging, the only debs I have ever packed have been for apt on arm-darwin [11:13] ogra, So, we should undo that. I'm still not tempted to undo it until we understand the i10n plan. [11:14] well, i'm happy to go with the defaults all arches use [11:14] * ogra drops the lines from the seed [11:14] If you want to have a seed commit today, I'm 100% in favour of doing anything to make armel less special in the seeds. [11:14] I just expect that we'll have to fiddle it again later. [11:15] why ? [11:15] we will inherit whatever desktop does [11:15] lilstevie, I *may* have time on Sunday, depending on your timezone, etc. If not, I'll try to catch you as soon as I have time. [11:15] :) [11:15] Because preinstall != live. [11:15] well it is 8:15pm friday here :p [11:15] Ah, a *good* timezone :) [11:16] :) [11:16] persia, well, the only difference is casper vs jasper [11:16] we use the live seed on preinstalled [11:16] So, yeah, there's a chance I'll have time Sunday evening then. [11:16] seed change pushed [11:16] lets see how much that saves [11:16] i guess we should come out below 800M now [11:17] Given that there is a *new* method of doing internationalisation in the works, I'm expecting *both* jasper and casper to need adjustment, along with live-build configu. [11:17] But yeah, for the weekend, we can have smaller images. [11:18] well, desktop will not go to bigger images for now [11:18] lilstevie, Be aware that the release manager has all sorts of requirements for generating images. In practice, this typically means that if we get a kernel into the archive in one cycle, we can have proper images the *next* cycle. That said, if your kernel is good enough, and there are testers, etc.., we may be able to work around that. [11:18] so they will rather drop langs than add [11:18] It's changing. [11:18] not yet [11:18] Stuffing bundles of langs into a single image may not be how it is done in the future. [11:19] as i understood we still go for 700M in oneiric [11:19] And there is no way to have any idea about this until next week. [11:19] persia: heh I don't think we will be working around that [11:20] Yes, oneiric images will be 700M. Nonetheless, per-locale customisations are happening in a *completely* different way than in the past, and much more comprehensively, which likely has implications about how locale-specific code ends up in default images. [11:20] lilstevie, Fine by me, as long as you don't mind it being a remix for 11.10. [11:20] i dont care about customizations :) [11:20] only about the default image [11:20] If there are enough users, etc. then we can apply to have proper images for 12.04. [11:20] Yes. Please read my last sentence again. [11:21] persia: that said I always tend to understate my stuff [11:21] persia: my problem is the lack of hardware support [11:21] lilstevie, It's a geographical limitation. You're just following your peers. [11:21] heh [11:24] persia: well there already have been some testers just FYI [11:24] on the utouch team [11:25] More folk always help, but we're going to need someone to commit to the milestone testing, which basically means being nearly continuously available (for respins) for ~3 days for each milestone release to ensure image quality. [11:26] And that usually requires user numbers in the 100s, unless one happens to get lucky and catch a great tester early. [11:26] hm, well I don't know about 100s :/ [11:27] Heh, yeah. That's part of why it's sensible to start slowly. [11:27] If you make something great, and then you tell your users that someone has to volunteer to help test in order to continue, you'll either get a volunteer, or you'll have confirmation that there isn't enough interest. [11:27] heh [11:37] hmm [11:37] so how do i make preinstalled images use the oem user [11:38] should that be created at image build time or by jasper [11:41] By jasper. [11:41] why ? [11:41] To parallel casper, and keep live-build config more similar. [11:41] (yes, there's messiness now, but I'd rather clean that up than add to it). [11:42] well, do you see a reason why preinstalled images shouldnt have an oem user and oem-config enabled by default [11:42] Remastering. [11:42] i actually think that code should move into the build process [11:43] For live also? [11:43] no [11:43] OK. Why should live and preinstall be different? [11:43] well, for remastering its actually an advantage [11:43] because they are totally different things by design [11:44] preinstalled images will always have oem-config installed [11:44] so why not enable it by default (including the user) [11:45] wrt remastering ... if you dont use the jasper initrd, you are screwed today [11:45] Why? [11:45] because jasper enables oem-config [11:45] I know of people who have extracted the rootfs from a preinstall, generated a *different* initrd, and used it on devices. [11:46] i know of people trying to use our preinstalled rootfs as is but without initrd :) [11:46] Heh. [11:46] if you only want the rootfs then you have to manually fiddle with it to get oem-config up [11:47] I had to manually touch /var/lib/oem-config/run [11:47] So the basis of my argument is mostly "There should be no difference between live and preinstall". [11:47] i.e. you have to do all the bits jasper does to the rootfs [11:47] But I can see the argument "There should be no difference between preinstall and the results of booting live and performing an orm install". [11:47] jasper should *only* care about partitioning and resizing [11:48] and the peripherial bits that includes like bootloader config and fstab creation etc [11:48] i want to get all unrealted hacks out of the code [11:48] OK. I can accept that. [11:48] enabling oem-config is one [11:48] And jasper might end up going away completely, replaced by spices, or similar. [11:48] and we dont even do it right atm [11:48] (or be the instrument of spice implementation) [11:49] you will always need the resize on boot bit [11:49] Right. You've convinced me. oem-config should be enabled by live-build. [11:49] which in turn means you will need to create fstab and bootloader config at the same time [11:50] that cant be handled by seeds only the package can be pulled in or be omitted by seeds [11:50] i dont expect jasper to go away as long as we have the resizing [11:50] Ah, and if jasper is pluggable, fstab can be generated dynamically, and bootloader config can be done by spice insertion to some conf.d. [11:51] well, bootloader config is something that should better live in flash-kernel-installer ... but that will require more changes [11:51] since its only available in udeb form atm [11:51] We could add it to oem-config. [11:51] Or, no, you need it earlier, don't you. [11:51] no [11:51] well [11:51] yes [11:51] heh [11:51] tricky [11:52] i need a change of the cmdline earlier [11:52] not necessarily a full new setup of the bootloader [11:52] We already did the work to have a ubiquity controller for flash-kernel-installer, so it would be handy if we didn't need it until oem-config runs, but because we need it early, jasper has to do it. [11:52] the actual setup could be done by oem-config [11:53] but that wouldnt get rid of bootloader code in jasper [11:53] If we're going to have bootloader code in jasper, let's use flash-kernel. [11:53] thats what it does ... just not for the setup [11:53] i.e. the generation of config [11:54] flash-kernel-installer won't generate the config? [11:54] flash-kernel-installer isnt existent in jasper [11:54] i would have to pull it into the initrd [11:54] Not all of it. [11:54] with a big penalty (lots of different bootloader deps) [11:55] So, the way ubiquity does it is to embed the flash-kernel source in the ubiquity source, and then copy flash-kernel-installer.postinst to somewhere useful when building the binary. [11:55] by current design, all of it [11:55] It then calls that script to do the setup. [11:55] i know how ubiquity works [11:55] (i worked on that code too) [11:55] Can't we do the same thing for jasper? [11:55] And inject only the bootloader support demanded by the spice? [11:56] yes, but to keep it generic you would have to pull all bootloader tools into the initrd [11:56] that will get huge [11:56] Yeah: just refreshing both our memories to make sure we're talking about the same thing :) [11:56] We don't need generic at that point: this is what spices are supposed to do. [11:56] That's the entire point of the two-stage image build process. [11:57] well, thats not how flash-kernel-installer is workigng currently [11:57] so that would need some massive redesign [11:57] I thought that flash-kernel-installer simply assumed that everything was present, but then only called the bit it needed for the board it was using. [11:57] modularization ... and support for initrd [11:57] flash-kernel-installer *makes* everything present [11:57] thats part of its job [11:58] it chroots and installs the bits and pieces for the currently used arch [11:58] Yes, but that's the dependencies. flash-kernel-installer.postinst doesn't do that on it's own, does it? [11:59] which means you need support for *all* arches in the ship seed [11:59] And flash-kernel-installer.postinst is *designed* to run from an initrd (the d-i environment) [11:59] Why? [11:59] flash-kernel-installer.postinst chroots and calls apt_install [11:59] flash-kernel-installer.postinst is not designed to be run from an initrd [12:00] it is designed to be run in d-i context [12:00] The d-i context *is* an initrd, but we stray :) [12:00] it expects certain d-i copmponents to be there [12:00] It calls apt_install for *everything*, rather than just the currently-detected platform? [12:01] no [12:01] Right. [12:01] its doable but as i said in the beginning it takes a lot of changes [12:01] Ah. because in the preinstall context, we don't have a chroot. Right. [12:01] and essentially a complete redesign of flash-kernel-installer [12:01] Let's not do that. [12:01] we do have a chroot [12:01] from initrd [12:02] So, why do we need to change anything? [12:02] apt_install is a no-op if the package is already installed. [12:02] if we want to use it out of context we need to change it [12:02] apt_install doesnt *exist* in non d-i initrds [12:03] there are plenty of calls to d-i tools in the scripts [12:03] you cant just dump it into an initrd [12:03] it wouldnt run [12:03] Ah, so we'd end up embedding all sorts of things, essentially duplicating ubiquity, and we'd get all sorts of annoyed trying to maintain it. [12:03] Right. [12:03] yeah [12:04] so it would have to become more modular (so you only pull in the snippets you need at initrd generation time) and would need a layer that can switcfh between d-i tools and normal initrd binaires [12:04] So, we have flash-kernel available in the chroot, right? And whatever bootloader support bits we need for the target? [12:05] and you would need arch specific hooks in initramfs tools so you can select which bootloader tools go into the initrd [12:05] Oh, but that won't generate the initial configuration. [12:05] right [12:05] No I don't. [12:05] I can control that by which packages I happen to have installed at initrd generation time. [12:05] the first change of the cmdline is the bit [12:05] for the actual final initrd we can actually use flash-kenrle-installer [12:05] * persia wishes someone would port grub2 already, *again* [12:06] *kernel [12:06] * ogra doesnt :P [12:06] flash-kernel-installer, or flash-kernel? [12:06] the former [12:06] from oem-config [12:06] Oh, right. Because that gives us a d-i context. [12:06] right [12:06] So, really, we just need to be able to boot *this one time*. [12:06] its only the jasper bits [12:06] where i parse the cmdline and adjust it after resizing [12:07] So, I don't believe there's a generic way to change the commandline. [12:07] We've different requirements for different bootloaders. [12:07] not generic, but pretty generic [12:07] we currently support what, two bootloader variants in ubuntu ? [12:08] u-boot and abootimg [12:08] redboot is gone from teh achrive and from flash-kernel since a few days [12:08] (and from d-i) [12:09] Yeah. I have to add some of it back one of these days, if I ever get around to upgrading my netwalker (I kinda wish someone would come out with a satisfactory replacement I could just buy instead). [12:09] But what I'd add back for redboot is *completely different* from what was there, so that's not strictly relevant. [12:09] ogra: Do you know if PXE boot is likely going to be an option for next? [12:09] And there's the messiness for the Nokia devices, but that's something else. [12:09] (or anyone else) [12:09] Daviey, "next"? [12:10] Daviey, the code is in our oneiric u-boot package [12:10] Daviey, we'll run some tests next week [12:10] Daviey, You want to watch https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-o-uboot-pxe-support andhttps://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-o-uboot-initial-usb-tftp-support-panda [12:10] Supposedly, as part of those implementations, we'll end up with docs that describe how to enable PXE for arbitrary u-boots (needs device driver porting) as part of that delivery. [12:11] persia, yeah, well, we largely dropped imx51 [12:11] and all bootloader code it had [12:11] or better lool dropped i just nodded :) [12:11] Except for the netwalker, all the i.MX devices I have use u-boot. [12:11] yup [12:12] most future devices will use fastboot i suspect [12:12] Dunno. u-boot has a lot of following, and Freescale supports it. [12:12] if we cover these two we should be largely generic ;) [12:12] (plus, we *could* have grub2, and not have to worry about any of this mess) [12:12] pfft [12:13] unlikely that you get the vendors to support it [12:13] Ah lovely! [12:13] took long enough to get most of them to u-boot [12:13] ogra / persia: we might be pestering you next week. :) [12:13] we hope so ! [12:13] Thanks! :) [12:14] Anyway, for supporting two bootloaders, should that be pluggable? [12:15] Have the bootloaders provide some file that, when jasper is installed, jasper uses to define *how* to change the cmdline? [12:15] That's likely more compatible with spices than jamming everything in jasper and hoping the initrd doesn't overflow. [12:15] I actually think we should consider grub as a third stage bootloader [12:17] lool, what would be second stage ? [12:17] lool, I'd love to have a discussion about why we shouldn't use grub as *second* stage, but I really want to figure out the design for pre-oem-config booting first :) [12:17] I'd love to see grub2 for arm [12:17] ogra, So, pluggable, or bundle-everything-in-the-initrd and hope we don't get too many bootloaders? [12:17] persia, well, on the ac100 i have exactly 4M for the initrd [12:18] That's a good argument for pluggable :) [12:18] every byte above makes the system oops [12:19] So we have /usr/share/jasper/bootloaders.d/*.conf, and we source that, and then call "fix_command_line()" ? [12:19] something like that [12:19] Oh, right. initrd. Change the names :) [12:19] And then we add the magic file to abootimg and u-boot. [12:20] right [12:20] So, here's the worry. The magic file will end up in the initrd after jasper is purged. [12:20] Do we care that much? They should be very small. [12:20] why would it ? [12:20] Because it lives in the bootloader package. [12:20] oem-config runs update-initramfs after jasper is removed [12:21] Right, but that won't remove the files from the bootloader packages. [12:21] but the hoooks that would install it to the initrd [12:21] s/it/them/ [12:22] the files live in the filesystem, but not in the initrd if no hook installs them [12:22] Aha, so it *would* be somewhere like /usr/share/jasper/... and then jasper would provide the hooks for initramfs-tools, which would be purged on jasper-purge, which would result in the magic files not being in the initrd when update-initramfs is called? [12:22] well, in /usr/shar/initramfs-tools/hooks, but yeah [12:23] Well, the hooks go there, but the bootloader implementation files? [12:23] the hooks define what ends up in the initrd [12:23] Yes. [12:23] actually /usr/shar/initramfs-tools/hooks/jasper does [12:23] But in order to end up in the initrd, stuff has to be in the filesystem. [12:23] /usr/shar/initramfs-tools/hooks/jasper is part of the jasper package [12:24] the bootloader config templates can come with the bootloader [12:24] And the bootloader packages need to deliver the implementations to the filesystem to ensure we don't have multiple (assuming we didn't spice the image to have multiple). [12:24] right [12:24] Right. I'm suggesting that the bootloader config templates should be installed to /usr/share/jasper/bootloaders/ or similar. [12:24] but they wont end up in the initrd ever if /usr/shar/initramfs-tools/hooks/jasper is gone [12:25] Where jasper ships either an empty directory or a directory containing only .placeholder to support this. [12:25] Right, which is the correct behaviour. [12:26] * ogra wishes he would find out why this 4M limit exists on the ac100 [12:27] Insufficiently hackable bootloader. [12:27] ogra: partition size? [12:27] lool, So, why wouldn't we want grub as second stage? Wouldn't using it as third stage add ~8 seconds to boot time? [12:28] persia: I'm not sure where the 8 seconds are from [12:28] ogra: is the ac100 fastboot? [12:28] Random guess on my part to load grub, detect time, timeout, and load the kernel. [12:29] lool, To put that another way, if we're loading grub2, why wouldn't we want that to be second-stage? [12:29] it's a bit of a complex story; we could discuss it next week if you like; first, you often need a SPL which just loads the real bootloader into the initialized RAM [12:29] then you need a bootloader which does good stuff, this could be grub; but we're already at the TPL [12:30] TPL? [12:30] invented that one just now for tertiary or third program loader ;-) [12:30] SPL being secondary program loader [12:30] Right. [12:30] the second stage loader is hard for various reasons [12:31] first, it's extrenely device specific; it's hard to make it generic [12:31] second, it needs to be extremely small [12:31] So, for example, on beagle, we do ROM -> FPL (xloader) -> SPL (uboot) -> TPL (linux), right? [12:31] no, ROM is first stage [12:32] xloader is a SPL [12:32] Ah, OK. [12:32] So you want ROM -> (something) -> grub2 -> linux ? [12:33] lilstevie, yeah [12:33] ogra: wonder if it is bootloader related, or if it is partition size [12:33] fastboot is a pita [12:33] i'm pretty sure its bootloader related [12:34] it seems to be related to the unpacked size [12:34] persia: that's right; the something could perhaps be UEFI related :-) [12:34] ogra: oh [12:34] i.e. i can squeeze more into a bz2 or lzma initrd, but that will cause an oops [12:35] lool, Right. We completely agree, but were previously using different nomenclature. [12:35] ogra: so maybe its memory hole isnt big enough [12:35] I also want grub2 as TPL. [12:35] lilstevie, right [12:35] persia: also, "something" might need to be in two pieces itself [12:35] in *some* pieces :) [12:35] so grub 2 might be QPL or something :-) [12:36] * lool lunch [12:36] ogra: FYI memory layout from bootloader is what was causing my issue too, turns out the drivers for 2.6.32 expected FB mem to be at 1 address and the new bootloader has the memory location offset a bit highre [12:36] higher* [12:36] lool, I'd really prefer a less capable *something* than a split one. For example, u-boot is often no longer used as SPL beause it has too many features to fit in the small memory barriers, but realistically most of those features aren't needed if handing off to grub2. The same applies, only moreso, for UEFI. [12:37] often used as ? [12:37] u-boot *is* an SPL, no ? [12:38] ogra, For panda, it's TPL. xloader is SPL. [12:38] well, yeah [12:38] for panda [12:38] (according to the nomenclature lool and I are using for this discussion) [12:38] usually its SPL though [12:39] omap is special since it doesnt fit enough into its rom apparently :) [12:39] else x-loader would just live on the board [12:39] preinstalled in rom [12:39] No. [12:39] x-loader is just a trimmed u-boot because u-boot can't all fit in the environment started by the ROM. [12:40] thats what i said, just the other way round :) [12:40] But nearly *every* ROM boot code ends up just jumping to somewhere to do setup, and isn't nealy as complex as e.g. x-loader. [12:40] in non omap boards that bit lives in rom [12:40] No. [12:40] So, ROM always just does a jump to somewhere after absolute minimum startup. [12:40] But ROM is *never* complicated. [12:41] (this is FPL). [12:41] Depending on the capability of the ROM, it *may* have enough of an environment to use u-boot as SPL, but it may not. [12:41] rom inits ram, loads the BL and jumps to it [12:41] in case of omap the initialized ram is to small [12:41] If one enables *all* the features in u-boot it's fairly easy to end up with needing something else as SPL. [12:42] hence the comment above '"something" might need to be in two pieces itself' [12:43] i didnt debate that :) [12:43] i just said that generally u-boot is SPL by design [12:43] My contention is that u-boot is an operating environment that neither knows nor cares where it's loaded. [12:44] that we deal with the special case of omap doesnt change that fact [12:44] It could be PPL and be happy. [12:44] (rom -> uefi -> grub -> linux -> u-boot, for example) [12:44] well [12:44] you could: rom -> linux [12:45] that doesnt make the kernel an SPL :) [12:45] Sure. [12:45] Yes it does. [12:45] for that particular case, yeah [12:45] but not generally [12:45] I don't happen to think it's a particularly *good* SPL today. Needs *lots* of work. [12:45]