[00:00] persia: someone wanted to do some omap4 cleanup on d-i [00:00] I think I mean "mx5". I've heard folk say that the same code supports the i.MX51 and the i.MX53, and that someone was calling that mx5 while adding support in Debian. [00:00] debian is likely enabling omap subarch [00:01] persia: yes, that someone was me [00:01] Will Debian "omap" support omap3 and omap4? [00:01] mx51 and mx53 are not yet compatible [00:01] Heh. Then you know what string I need more than I :) [00:02] yes, omap in debian will be for omap3 and omap4 [00:02] They aren't? I thought linaro had a kernel that worked on both. [00:02] persia: is not about what I need, I am trying not to break your stuff [00:02] If "omap" in Debian is for both omap3 and omap4, then it makes sense for Ubuntu to carry "omap4" is a patch, for as long as it continues to be required. [00:02] as someone submitted a patch which removed omap4 from libdebian-installer [00:03] As long as we know about it, it oughtn't be a disaster. [00:03] persia: ok - but there are old trees with omap4 and documentation all over teh place [00:04] NCommander, Are you about? Would you have time to review this with zumbi to figure out what makes sense as an Ubuntu patch? [00:04] persia: this was the thread triggering this question.. http://lists.debian.org/debian-boot/2011/06/msg00184.html [00:06] Ah, and now it all makes sense. [00:06] Yeah, it's probably better to leave "omap4" and "imx51" in the reserved list for now, as this makes the Ubuntu patching easier (reassinging some boards,etc.). [00:07] yes, that was what I thought [00:07] we'll see how we end up with mx51 and mx53 [00:09] What's outstanding there? A merged kernel, or something larger? [00:11] persia: is it just an offset issue [00:11] at boot time [00:13] Hrm. That confuses me. I've been told that folks with both Efika smartbooks (mx51) and Quickstarts (mx53) are booting with the linaro kernel. [00:13] I thought that was the same kernel. [00:14] http://lists.debian.org/debian-arm/2011/04/msg00067.html [00:14] apachelogger, What's your `uname -a` output? [00:15] persia: well, maybe it has been fixed [00:15] that issue was raised back in april [00:15] I have not tested mx53 stuff yet [00:16] Uwe also seems to be talking about mainline, and I suspect Linaro's Freescale Landing Team has a number of patches in the pipeline. [00:18] persia: yes, Uwe is mainline.. but certainly if that is in Linaro eventually it'll get into mainline [00:19] Sometimes the patches need a fair bit of rewriting :) [00:19] if it is not there yet... I need to update myself [00:19] (but yeah, it's heaps better than the old abandoned vendor trees) [00:19] well, there is not much involved into have mx53 and mx51 in one kernel [00:20] we really hoping for unified kernel [00:21] I think there is one. Unfortunately, jcrigby, who'd know for sure, seems to be away from IRC this week. [00:22] Unfortunately, my git-fu isn't up to finding shortlog difference between trees sufficiently to distinguish which patches may have been applied to achieve this. [00:26] well, that's upstream call I suspect [00:28] Heh, well. Depends on your feeling towards distro-patches :) I suspect that for Ubuntu we'll be telling base-installer to use the linaro kernels (since they regularly get uploaded into the archive). I'm not convinced Debian wants N kernel source packages, which makes it much harder to do without upstream support. [00:35] persia: debian kernel team sticks to upstream/mainline [00:35] Sensibly :) [00:35] and they have a policy of only backporting patches which have been accepted into mainline HEAD [00:35] Ubuntu kernel team does the same (mostly), but there are something like 6 kernel source packages in Ubuntu, of which only one is managed by that team. [00:35] unless it is a bugfix [00:36] For Ubuntu, even bugfixes get asked if they are upstream (although I suspect some that aren't yet get applied) [00:36] well, it becomes insane if you do it other way, you need an upstream to distribute [00:36] Debian distributes GNU [00:36] free and open stuff [00:37] Ubuntu is more into commercial world, I want it to work even if it is not open/free [00:39] I mean Ubuntu besides being driven by business, it also does not comply to Debian free and open source guidelines... [00:39] It's not about free/non-free and it's not about money. [00:39] in a sense Debian is freedom taliban [00:39] persia: I was not trying to be annoying that was just my point of view [00:39] All the extra kernels in the archive are GPLv2-only, and some of them are uploaded by people I know not to be receiving any compensation for doing so. [00:40] I agree that having a single upstream is *lots* easier to manage, and generally cleaner. [00:41] well, you really do not want to carry 6 different kernels for x86 [00:41] then dealing with bug reports is insane [00:41] They have 6 different source packages. [00:41] (but I think we only have 2 source packages for x86) [00:41] And different binary package names [00:42] when talking about free/non-free, I was thinking on ti-sgx 3D drivers, nvidia stuff, etc... [00:42] I don't believe any of that is in Ubuntu. [00:42] and surely there is community around Ubuntu [00:42] TI has a PPA in which they distribute some stuff. [00:42] I don't think nVidia has one. [00:43] uhm.. I might be wrong [00:44] persia: but then why fork Debian and not work with it? [00:45] I wasn't involved in that decision. [00:45] At the time, I was following Debian mailing lists, and had the impression that there was a desire to do ~1000 NMUs, which were considered to be unfreindly at the time. [00:47] I believe the fork comes from the desire to be able to upload things *without* considering whether it's NMU, and the desire to release every six months (Ubuntu was announced around the time that sarge was looking like it would never release) [00:47] I think many Ubuntu Developers, especially most of those who have been around a while, do also work in Debian in one way or another. [00:48] I'm not sure it's fair to say "and not work with it" [00:48] persia: yes, that's for sure [00:48] persia: well in a way we use debian tweaked for our needs at work [00:49] Now, since 2005 NMUs in Debian have transitioned from being an injury to being a help to other maintainres, there's lots more team maintainership, the DAM lock that nobody understood is gone, etc. [00:49] we got some extra packages in internal repo [00:49] So lots of the initial rationales for Ubuntu would probably be considered differently if considered today. [00:50] But at this point, deciding to not have Ubuntu gets messy and complicated: too many people have too much invested in continued existence. [00:51] As some of the first changes in Ubuntu were toolchain patches, which required rebuilding all the rdepends, I don't think "extra packages in a third-party repo" would ever have worked. [00:52] Ubuntu continues to be a testing ground for new toolchains in Debian, which I think benefits Debian in terms of patches available for FTBFS at least as much as it benefits Ubuntu in terms of tighter optimisations. [00:53] persia: I agree [00:53] surely one is testbed of the other [00:53] Mind you, there's been *lots* of argument about this, from lots of directions in the past. There have been some periods where cooperation was weak. [00:54] yes, lots of flames [00:54] some of the toolchain diffs (hardening defaults) were brought up at UDS in the Debian health check session [00:54] But I very much hope that more teams follow the example of the Mono/CLI team, where a common set of folk have upload rights to both distributions, tend to do most of their stuff in Debian (except where variation is required to comply with other variation), and everyone stays (mostly) happy. [00:55] persia: some DD are annoyed to not be able to upload to ubuntu [00:55] and find some packages are not in sync [00:55] zumbi, Sure, but some DD *can* upload to Ubuntu. There's more than a few that have requested (and been granted) upload rights for the stuff they maintain. [00:56] DEX is great opportunity to improve cooperation [00:56] persia: I did not know about that.. in any case I am not against any [00:56] Those DDs who are annoyed to not be able to upload should demonstrate they are watching LP bugs, and apply to get upload. [00:57] On the other hand, some DD complain and say that Ubuntu should sync their latest upload all the time: in several cases this has broken chunks of the archive that go beyond that specific package late in the release cycle. [00:57] This is especially common when Debian is just coming out of freeze while Ubuntu is entering freeze. [00:58] And some DDs don't bother to test whether their new uploads even build under Ubuntu (but still insist on sync) [00:58] yes, slightly similar, but not same [00:59] Luckily, those are the extreme minority, but it's fear of that sort that leads to the process of requiring folk to apply and demonstrate they do care about Ubuntu (which has been described as overly bureaucratic by some) [00:59] I think there is material to write a book [00:59] Several :) [01:00] well, I think the base system is well built but either debian and ubuntu developers [01:00] I have lots of friends that are working or have worked for canonical [01:06] There's lots of Ubuntu Developers that don't work for Canonical as well (although, to be honest, we've not been as good at recuiting new developers lately, and Canonical has hired a lot of folk, so I'm not sure whether Canonical employs a majority currently) [01:09] It is quite amazing how all that is structured [01:09] it is hard to understand properly :) [01:09] I am not sure I got contributions to ubuntu, but at least if I fix something in debian I ping the packages in ubuntu, so they can check [01:10] and I have even signed the ubuntu code of conduct [01:10] What's your LP account? [01:10] but not sure how can i help ubuntu, I try to keep debian alive at least on embedded arches which have been in my interest since the beginning [01:11] persia: my nickname [01:12] You've not been granted specific credit for any patches in Ubuntu (although I know you've been helping folk for a long time). [01:12] I do not maintain much packages in debian, but fixed tslib driver for X.org in debian and pinged the bugreport in ubuntu [01:13] well, not helping, really is cooperation [01:13] Sure: I tend to think of cooperation as "folk helping each other" :) [01:14] If your patches are getting applied in Debian smoothly, and flowing to Ubuntu well enough that you're comfortable, I'd say you have nothing to worry about. [01:15] If you want to deploy patches that aren't being accepted, or there are issues with getting stuff into Ubuntu that you want to fix, then it may make sense to prepare debdiffs for bugfixes and send them to Ubuntu bugs for application. [01:16] But it all depends on your personal motivations, and whether you have any desire to identify as an "Ubuntu Developer". [01:16] I see [01:16] well, I don't care.. I would like to close LP#1 :) [01:17] I think that was that one bug Mark wrote time ago [01:17] That's getting very close to closed, unfortunately not from our work (iOS, Android) [01:18] sadly, yes [01:19] but still .. they are around [01:19] Oh, indeed. And lots of the Android work ends up being directly useful to us. [01:19] later moves with Nokia were not good [01:20] I am still waiting for the ubuntu-phone [01:20] I keep hearing good things from Nokia, although for stuff that isn't phones. I'm not yet ready to have an opinion. [01:20] I believe Kubuntu Mobile has a working dialer and some baseband support. [01:21] persia: no, you need to ship actual devices, not expect people to fit that into a mobile [01:21] pre-installed ubuntu phones [01:22] Yeah, well. All we can do is build it, and hope they come. [01:22] well, you need to contact manufacturers [01:22] Sure, some of us, as individuals, can go talk to ODMs, etc., but at that point I'm not sure that it's still part of the wider "we". [01:23] I'm not convinced that it's yet possible to deliver a product with turnkey free software. [01:23] HTC has recently open the bootloader [01:23] to make their devices more hackable [01:23] If we can reach that point, where it just works, and can usefully be installed on nearly any phone, then it becomes a relatively safe option for someone to release a phone based on that stack (rather than requiring in-house development effort) [01:23] not open as in source, but open as in access [01:24] Given the number of tablets and handhelds released with Ubuntu Jaunty when the ARM port first became available, I would expect several devices to appear shortly after it was known to work. [01:24] we build a lightwriter for disabled people, not only helps them to speak up but it also works as a phone [01:25] (mind you, most of this was not available outside the Chinese market, but that's the hot location for early adoption in consumer electronics: everywhere else folk are very conservative) [01:26] yes, the Chinese just go for it.. [01:26] I know Anthony Fok and Paul Liu [01:27] great developers [01:27] Right. There's lots of cool stuff to do. I believe that we (being developers) need to focus on making sure that our software stack works, is easily adapted to a wide variety of hardware, and is widely available at no cost (free code is something we care about. free beer is something the manufacturers care about) [01:28] Whereas we (being the free software community) need to encourage or develop entrepreneurs who will take these things to retail devices. [01:29] Yes, I have thought many times to develop some hardware and use free software to develop retail devices [01:29] but all of it is complex [01:29] It's no more complex than software :) It's just different. There are very few folk who can do both. [01:30] getting parts sorted [01:30] MOQs [01:31] Oh yeah. [01:31] Anyway, getting late in the morning for me, and I must run. Have a good evening. [01:31] hardware is .. don't know how to describe.. hardware to be ready for production is just tough === Lopi|idle is now known as Lopi [01:31] persia: sure.. bye [01:32] persia: just one more thing, linux is the testbed of new processors which tomorrow (years away) will be part of products, besides mobile world which it changes so fast [01:33] I wish it was that simple. [01:33] Lots of the things that get tested (much of which goes mainline) ends up being PoC to drive design wins, which end up with derivations for production deployment. [01:34] Even with many of the SoC vendors collaborating within Linaro to help make BSPs be mostly upstream(able) code, I suspect there remain cultural barriers to having vendor devices mainline enabled. [01:35] (with the exception of a few bright spots, where vendors are very cooperative) [01:36] In many ways, I welcome Windows 8 to the game: it helps the conversations about having hardware be a base platform on which arbitrary software is delivered. [01:36] yes, it'll bring all the fun on how broken it is [01:36] At least with more things reaching mainline these days, the SoC vendors haven't dropped support for recent kernels before the devices ever reach retail. [01:37] omap is keeping up with community very well [01:37] I don't care about the actual operation of Windows 8: the reasons I am unlikely to use it have nothing to do with what it does or who makes it. [01:38] I care more about how the presence of multiple operating system choices for a given platform provide incentives for board manufacturers to have known working generic solutions. [01:38] TI does good. I like TI. I'm not happy with how bootstrapping works: it still requires omap-specific code. [01:38] it is already happening due to android, linux duality [01:38] From what I understand, this is a ROM issue with ROM inside the SoC, which can't be fixed until OMAP6 or OMAP7. [01:39] Android and Linux are almost identical code (ignoring userspace). [01:39] As a result, the *same* set of enablement patches is likely to work for both. [01:39] yes, omap has a ROM which calls x-loader, u-boot, etc... [01:40] The nice thing about Windows 8 is that the Android/Linux patches *will not apply*, which means thinking about generics at a design level. [01:40] Anyway, I'm getting very late :) It's always fun chatting with you, but ... [01:40] omap ROM code loads x-winloader which loads winkernel [01:40] persia: sure, later .. :) === asac_ is now known as asac [09:47] zumbi, to answer yesterdays question, imx51 was just removed in ubuntu in favor of mx5, omap4 is one of our supported arches so needs to stay [09:48] IMAGES !!!! [09:49] http://cdimage.ubuntu.com/daily-preinstalled/20110616/ [09:49] yipiee [09:49] hmm, nearly 1G [10:04] ogra_: what's the difference between omap and omap4? [10:05] in the cdimage build [10:05] omap4 has a special kernel package [10:05] and special boot options [10:05] for omap4 we also provide additional packages that make it easy to enable the TI [10:05] PPA [10:06] which holds the sgx drivers and HD video codecs etc [10:06] I see.. thanks [10:07] the prob is, while you can have a jiont kernel packqage for all omap arches, you still need a separate binary bootloaders and cmdline options atm [10:07] -s [10:08] ogra_: part of that can probably be solved with boot scripts [10:08] not really [10:09] TI initializes half the HW in their bootloaders instead of the kernel ... [10:10] if you would have x-loader and u-boot binaries that support all omap arches and only switch through boot scripts, you would end up with huge binaries [10:10] and i even doubt a multiarch x-loader would be possible at all [10:13] i fear until UEFI gets default for ARM we will have to live with SoC specific bootloader binaries here [10:13] yes, x-loader upstream maintainer was a bit sick of all that [10:14] Why doesn't TI just boot directly into kernel and this one is responsible to do everything [10:14] no idea [10:15] don't really need u-boot, unless you rely on it to initialize everything [10:15] for the build cluster we tried to use a raw kernel boot ... and initially ended up with no MMC and no USB [10:15] getting that initialized needed a good bunch of first stage bootloader hacking [10:16] sadly you need x-loader, there is not enough memory to carry u-boot [10:16] so x-loader needs to init the ram first [10:17] now, everything starts to make sense [10:17] sadly it grew more heads over the years it seems [10:17] as well as u-boot did [10:18] The processor only has 64K memory on boot, that's why x-loader is the way it is. It initializes ram (and a bunch of other crap), then u-boot can load and do more. [10:18] so even if you wanted to do something like booting a raw minimal kernel and then kexec into something full, you would still need x-loader and u-boot [10:18] Well, x-loader at least. [10:18] which makes kexec moot since it just adds boot time for no benefit [10:18] You can boot a kernel from xloader. [10:19] well, you should be able to dd a binary header in front of uImage that replaces x-loader [10:19] ogra, would an xloader/uboot that supports OMAP3 and 4 be that huge? Even if it were double the current size - which it probably would not be - it's not an issue [10:19] at least with newer omaps [10:20] Can't. not enough memory to load both. [10:20] janimo, for x-loader it is ... as GrueMaster said above, 64k is your limit [10:21] not having both binaries but one that handles both. Is the extra code/data so much different it would increase the size beyond what it fits? [10:21] for u-boot it might be possible to be a big multisoc binary [10:21] but surely for the cost of bootspeed [10:23] is it true that TI had problems with memory controllers as those did not match, so omap was unable to use memory (as LPDDR) [10:23] on XM, yes [10:23] (beagle XM omap3) [10:23] yes, I heard on 3530 early revs [10:23] all this is just insane.. :) [10:24] XM used 36/37 iirc from start - or not? [10:24] 34/35 was on normal beagleboard [10:24] the wonderful world of ARM :) [10:24] I hope for cheap ARM board with 2MB of flash on board [10:25] so there will be space for bootloader so boot from usb/sd/sata/network will be easy [10:25] i think you will see flash on board less and less [10:25] eMMC costs only half of i t [10:25] ogra_: flash/emmc/esomething/whatever [10:26] a way to just connect power and get board booted [10:26] hrw: sounds about right, xM using DM3730 [10:27] ogra_: if you want to use sdio on panda you have to solder second sdmmc or use other computer to send bootloader over usbdevice [10:27] there is "Automotive eMMC" much more reliable/tested than current eMMC [10:27] I miss real developer boards [10:29] I need to play with TI Wilink module, I hope it performs as expected [11:17] oh, there goes tomboy [11:17] Good morning [11:22] A little question, if I may. I cross compiled kernel for Beagle (that is, for arm). In parent directory (relative to kernel sources) I have now 5 .dev biles and a lot of .udeb files. What are .udeb files? Is it sufficient if I install linux-image-2.6.38-10-omap_2.6.38-10.44_armel.deb and linux-libc-dev_2.6.38-10.44_armel.deb? What are -versatile packages? (ok. Maybe not a little question, but I am tired as hell...) [11:23] udeb files are packages used by debian-installer [11:23] udebs (micro-debs, but created with an assuption of weak unicode support) are only for the installer. [11:23] you dont need them if you dont build an installer image based on d-i [11:23] Ok, good. [11:23] So only *.deb are of my interest then.. [11:24] you should really make your build command more explicit [11:24] -versatile is another arm subarch [11:24] I just followed manual pointed by rsalveti ;-) [11:24] It was not very... um, explanatory. [11:24] That doesn't have instructions for only building some flavours of the kernel? [11:25] fakeroot debian/rules binary-debs should just build the linux-image and headers packages [11:25] http://www.omappedia.org/wiki/Ubuntu_kernel_build_alternatives [11:25] sigh [11:25] ogra, That still builds all the flavours though [11:25] why didnt you use any ubuntu documentation instead ? [11:25] in manual there is binary-arch [11:25] not binary-debs [11:25] persia, oh, right, its the main ubuntu soucretree [11:26] * ogra_ forgot [11:26] ogra_: I used what rsalveti told me... [11:26] garagoth, You did the right thing. We're unhappy with the docs, not with your execution. [11:26] well, there are about three very detailed wikipages on the ubuntu wiki [11:26] garagoth, You did more than you needed, because the docs suck. [11:26] Just use the "omap" kernel .deb on your beagle. [11:26] Ok. Many thanks. [11:27] ogra, I thought the omappedia page was based on one of them [11:27] * persia is looking [11:27] ogra_: If you would be so king and provide a link to better tutorial... [11:27] persia, well, as the omappedia pages are all based on something ... the prob is there was a snapshot taken but the updates dont move over [11:28] ogra, https://wiki.ubuntu.com/Kernel/Action/BuildKernelPackage doesn't help much :( The wiki hates me. [11:28] I agree that it's better to use the w.u.c source, but we have to know a good one, and I fear the messiness of w.u.c is biting us here. [11:28] persia: heh, this is even shorter then omappedia... [11:29] garagoth, Sure, but it skips a lot, doesn't explain how to cross compile, and still results in what you got. [11:29] :-) [11:30] https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel is one [11:30] https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel is a bit nicer, but I thought there was a cross-compile one. [11:30] there is amitk's blog [11:30] but thats not up to date, i think hrw had a more up to date one [11:31] ogra_: yes, go to hrw's blog post [11:31] No, there's a wiki page about it. [11:31] If that's not up-to-date, then we fail at docs. [11:32] http://marcin.juszkiewicz.com.pl/2010/10/19/how-to-cross-compile-arm-kernel-under-ubuntu-10-10/ one? [11:32] * ogra_ likes https://wiki.ubuntu.com/SergeHallyn_ppakernels [11:32] short and simple [11:32] Doesn't cover the use case though. [11:32] no [11:33] covers mine though :) [11:33] https://wiki.linaro.org/Resources/HowTo/PackageYourOwnKernel is more complicated [11:33] Only because you're refusing to participate in Ubuntu these days. [11:33] who uses cross compilers anyway :P [11:33] ... me? [11:33] persia, huh ? [11:33] me [11:33] :) [11:33] ogra, Pushing kernels to PPAs when they ought be in the archive. [11:33] pfft, *REAL MEN* compile natively :) [11:34] no way [11:34] two hours to get a kernel [11:34] persia, it cant be in the archive yet ... [11:34] i would prefer to pull myself a tooth [11:34] I cross-compiled this kernel for few hours. I took looots of disk space. [11:34] No way I would do this natively... [11:34] ogra, Why not? [11:34] garagoth: define looots [11:34] ppisati, i just always have a tree around where i only remobuild changes [11:34] *rebuild [11:35] only if i know they work i roll a package [11:35] persia, because i cant upload to natty :P [11:35] (and even if i could i wouldnt gain any benefit from that) [11:35] The rest of us are working on oneiric these days :p [11:35] hrw: looots == 7.9 GB [11:35] ogra_: add kernel to oneiric and provide it also in ppa? [11:35] * persia stops teasing ogra [11:35] garagoth: 8GB for kernel tree? [11:36] * ppisati tries to figure out what's the plan for oneiric/ti-omap4 [11:36] hrw, if you donate me 24h every day :P [11:36] this is what I have in kernel dir when cross-compile finished [11:36] garagoth: huge [11:36] inclugind generated packages [11:36] garagoth, you did it wrongly [11:36] garagoth: good that my panda has still 153GB free on /home [11:36] ops. 135GB [11:36] you only wanted an omap3 beagle deb, but built *everything* [11:36] hrw: USB HDD ? [11:37] ogra, Yeah, but that's our fault: the documentation sucks. [11:37] garagoth: yes - 320GB sata [11:37] ogra_: Now I know. I blame documentation :D [11:37] actually to cross compile i do: [11:37] export $(dpkg-architecture -aarmel); export CROSS_COMPILE=arm-linux-gnueabi- [11:37] hrw: How you connected SATA to Panda? [11:37] fakeroot debian/rules clean; fakeroot debian/rules binary-$flavour [11:37] garagoth, ogra@isis:~/kernel/linux-ac100-2.6.37$ du -hcs [11:37] 501M . [11:38] oh, wait, thats unbuilt [11:38] :D [11:38] [flag@newluxor ubuntu-natty]$ du -sk . [11:38] 3937700 . [11:38] :P [11:38] 3.8G [11:39] still to much if you only build the linux-image and -headers debs [11:39] binary-omap -> omap3 [11:39] fakeroot debian/rules binary-omap [11:39] natty/master [11:39] if you have any recepie to cut it, i'm all ears :) [11:39] doesnt that roll udebs and -docs and the like (and ddebs) [11:39] when i'm doing bisect/bug finding i use linus vanilla [11:40] copy .config from some ubuntu kernel [11:40] and then make uimage [11:40] it works and it takes much less time and space [11:40] nope [11:40] yeah [11:40] onlye kernel and header [11:40] thats how i do it for the ac100 too [11:40] Oh my. The page on the wiki got removed as part of Kernel Wiki Gardening, and replaced with a link to amitk's old blog post. [11:40] only for a release i actually roll a test package [11:41] btw, one day i want to find out what are the minimun required configs to make a vanilla kernel boot an ubuntu userland [11:41] garagoth: usb->sata enclosure? [11:41] garagoth, Sorry. For now, the omappedia page is the best one, but if you look at the Ubuntu pages, you can find ways to build fewer kernels to achieve your goals. [11:41] persia: Linking to someones blog from wiki for official instructions... well, looks unprofessional :-) [11:41] Especially when the author of the blog post recommends a different resource (see backscroll). [11:42] hrw: Mm. And what transfer rates you have? I wanted to replace my home server with a panda/beagle cluster [11:42] In general, we don't do much with cross-compiling (except hrw). [11:42] garagoth: poor - 20MB/s max [11:42] hrw, You should take over some area of the wiki, and build the comprehensive cross-compilation resource, and make all the other wikis (e.g. omappedia) point there. [11:43] persia: sounds like a plan [11:43] \o/ Real Documentation! [11:47] ppisati, didnt you have a spec for that ? [11:47] * ogra_ thought he saw one [11:48] ogra_: about what? [11:48] btw, one day i want to find out what are the minimun required configs to make a vanilla kernel boot an ubuntu userland [11:49] ogra_: nope, unfortuntaly no [11:49] oh ? [11:49] did it get dropped ? [11:49] never heard of a spec about it [11:53] YESSS!!!!! i2c bus 2 working !!! [11:53] But for some reason there is no entry about expansion board in dmesg... hum... [11:54] ppisati, yeah, i only saw the workitem on https://launchpad.net/ubuntu/+spec/other-kernel-o-config-review ... seems i mixed that up [11:57] ogra, The minimums are tricky (but there is work to document them). There's a number of cases where things work for *some* systems and break horribly for others, because of assumptions in userspace about kernel config that only are exposed in non-default environments. [11:57] sure [11:58] * ogra_ didnt say it was an easy task [11:58] :) [12:01] Heh, yeah. But seriously, I believe the kernel team has been collecting this data since ~karmic because of some regressions discovered at karmic release because the release config didn't match userspace expectations. [12:02] I doubt they have *all* the quirks documented yet, but there ought be a fair collection of information. I forget where, but remember apw telling me that it was in git somewhere. [12:03] Hrm. The magic summon-the-man-who-remembers-stuff-about-the-kernel incantation didn't work :( [12:04] persia, collecting which data ? [12:04] LOL [12:04] it worked :) [12:04] apw, Which kernel options are required to match userspace expectations for Ubuntu. [12:05] ahh i see, we have been codifying the values of ones we have found to be required, in the enforcer file, but that doesn't cover everything which is required sadly [12:05] Where is the enforcer file, so ogra can have a peak at the current knowledge? [12:06] persia, i know where it is i think [12:07] ogra@isis:~/kernel/linux-ac100-2.6.37$ ls debian.ac100/config/enforce [12:07] debian.ac100/config/enforce [12:07] here we go [12:07] apw, Thanks! [12:08] ogra, Good luck. If you find more required configs, please make sure they reach that file for all the kernels. [12:08] i dont get why its in the flavour subdir though [12:08] since it checks lots of general values ... that should just be in debian/ [12:08] Because debian.foo/ generates debian/ so anything in debian/ is subject to wiping. [12:09] only parts of debian/ [12:09] Yeah, well. debian.foo/ is where all the kernel team work happens. [12:09] They like to leave debian/ alone if possible, considering it strange black magic (which it is) [12:10]