**** BEGIN LOGGING AT Sun Mar 07 02:59:58 2010 Mar 07 03:01:47 DanaG: How did you set up your environment? Mar 07 03:20:21 I used a minimal rootfs image and kernel from rcn-ee. Mar 07 03:31:53 How did you construct the minimal rootfs image, or did you get it also from rcn-ee? Mar 07 03:34:39 The latter, yes. Mar 07 03:35:57 Have to wait until he's about then. The package relationships *should* enforce it being correct, but I'm not sure the minimal installs get enough testing. Mar 07 03:36:16 It's also odd that I get "class driver suspend failed for CPU 0" Mar 07 03:37:51 hmm, I wonder if there Mar 07 03:38:04 if there's any point to putting kernel in nand with rootfs still on sd card. Mar 07 03:38:07 eh, probably not. Mar 07 03:38:33 On my primary armel device, I put both kernel and rootfs on nand. How much space do you have in nand? Mar 07 03:39:56 Just 256 megs for rootfs. Mar 07 03:42:13 interesting... screen as serial console, with another 'screen' underneath, doesn't resize properly. Mar 07 03:43:28 256MB isn't really enough to fit Ubuntu. Mar 07 03:43:36 For sure. Mar 07 03:43:44 hmm, is there anything that WOULD be worth putting there? Mar 07 03:43:58 Depends on what you're doing. Mar 07 03:44:30 You could put / there with /usr and /var elsewhere, but that may not help that much. Mar 07 03:44:57 yeah, not worth the pain of /var being separate. =þ Mar 07 03:45:02 If you don't install that much, you could probably put /usr/bin there. Mar 07 03:45:12 (requires some hackery on setup) Mar 07 03:51:20 "Class driver suspend failed for cpu0" Mar 07 03:51:23 weird. Mar 07 03:52:59 Very. Mar 07 03:55:37 actual dmesg doesn't give any additional info. Mar 07 04:22:17 heh, sensors-detect assumes PCI must exist. Mar 07 04:29:27 If you can, please fix that :) Mar 07 04:29:41 It should work for i2c with no pci just fine. Mar 07 04:37:04 hmm, looks like it's too deeply coded to depend on PCI for its looking-around. Mar 07 04:38:58 Probably :/ Mar 07 04:42:25 Better logic would be this: check for pci i2c; if not loaded, load them. Mar 07 04:42:32 Now, even if that fails, go on and check all i2c buses. Mar 07 04:45:17 Why? Shouldn't it check for each bus type and only probe if the bus exists? Mar 07 04:45:43 Something like a combination of modprobe and sysfs inspection (to cover in-tree AND external modules) Mar 07 04:47:42 yeah, or if it's really lazy, just look at already existing i2c devices in i2c-1 through i2c-whatever. Mar 07 04:52:26 I think it makes sense to write slightly more robust code :) Mar 07 04:54:02 well, if I were given a choice between what we have now, and that "just use i2c devices already there" way, I'd choose the latter for this ARM thingy. Mar 07 04:54:22 do you have mtd support here? Mar 07 04:54:57 Baybal: How do you mean "mtd support". The answer is probably yes, but there are a few bits not yet working perfectly.. Mar 07 04:55:27 mtd booting Mar 07 04:55:33 and mtd as root Mar 07 04:55:51 Those certainly work: the gap is really mtd install. Mar 07 04:56:23 So, to get MTD set up like that, you need to boot in some other way, and then format the MTD, set it up for filesystems, and then manually install stuff. Mar 07 04:57:05 Right now I like ubifs for / and jffs2 for /boot, but my opinion is changing as I investigate what is required to make install work smoothly. Mar 07 04:58:00 DanaG: The trick is that the same code has to work for all architectures: it's a huge pain to try to have the script be different for different arches. Mar 07 04:58:01 i think jtag install is the only option on the most of devices now Mar 07 04:58:31 Baybal: I don't. Most devices have some way to boot off SD or HD (although you may need to tweak the bootloader) Mar 07 04:59:02 ah, as it is right now, it DOESN't work without PCI. bleh. Mar 07 04:59:09 DanaG: please fix :) Mar 07 04:59:10 no, even those last generation advanced socs lacks it Mar 07 04:59:29 Baybal: Hrm? What device do you have that cannot boot off SD or HD? Mar 07 05:00:16 like my cell phone Mar 07 05:00:23 lots of others Mar 07 05:00:57 the only advanced soc which had SD boot I know is TI omap Mar 07 05:01:12 i.MX51x does as well. Mar 07 05:01:52 But I only have i.MX51x and Orion9x devices, so I don't really know about others. I think I have some StrongARMs too, but I haven't played with those in a while. Mar 07 05:03:08 like nvidia tegra, qualcoms... Mar 07 05:03:51 and most of them are thought as advanced Mar 07 05:04:03 also samsungs... Mar 07 05:04:08 OK. So, how do the development boards for those platforms boot? Mar 07 05:05:12 on harmony boards there are standalone nor with bootloader Mar 07 05:05:28 which then tries to do booting Mar 07 05:05:55 some manufacturers simply don't have any kind of dev boards Mar 07 05:06:17 hmm, how about the marvell stuff? Mar 07 05:06:28 don't know Mar 07 05:06:32 nvidia tegra... wonder what the driver situation is like for those... Mar 07 05:06:37 would it be same as nouveau? Mar 07 05:06:48 much better than most of other arm socs Mar 07 05:08:48 like qualcomm has tons of code with no documentation Mar 07 05:09:14 I doubt that anyone doesn't produce dev boards (although they may be very difficult to get). Mar 07 05:09:28 and different versions of kernel per device running on the same chips Mar 07 05:09:50 From others I hear that marvell can boot off SD. Mar 07 05:10:08 (and my onions can definitely boot off HD) Mar 07 05:10:16 something I wish: I wish somebody would port 2.6.28 kernel to the realtek RTL8186 (Lexra MIPS) thingy. Mar 07 05:10:34 DanaG: Have you checked with the Debian MIPS folk? Mar 07 05:11:57 I've looked at the kernel itself, and it doesn't seem to support Lexra. Mar 07 05:12:10 Is there out-of-tree support somewhere? Mar 07 05:12:31 http://www.sondigo.com/sirocco/overview Mar 07 05:12:36 Only in 2.4 kernel. bleh. Mar 07 05:16:28 like qualcomm have 2 kernel with totally different stuff for 2 phones running exactly the same chip Mar 07 05:17:30 Oh yeah, and that kernel is not 2.4.32 OR linux-mips 2.4.32 -- it's god-only-knows what. Mar 07 05:17:47 It's so bad, you might as well buy a beagleboard and a USB sound card. =þ Mar 07 05:18:20 http://www.sondigo.com/node/229 Mar 07 05:26:18 I think at least a fs image + kernel with embedded initrd would be nice Mar 07 05:26:35 so it would be possible to flash and boot over jtag Mar 07 05:29:51 Baybal: So, what's required to boot over jtag? We can definitely construct rootsfs and initrds. Mar 07 05:30:35 Just bootloader and image understandable to it Mar 07 05:30:47 the mechanism works this way Mar 07 05:31:35 first you flashes memory over jtag to non boot partition Mar 07 05:31:52 then flashes bootloader to boot partition Mar 07 05:32:12 then starts all this things and hope they work Mar 07 05:32:54 so we need just a well compact set of images in popular flash filesystems Mar 07 05:33:28 I know for the old Zaurus devices, there was this "kexecboot" loader that was made for tiny in-flash execution. Mar 07 05:33:51 So, the kexecboot loader then goes off and loads the real kernel. Mar 07 05:34:14 usually something like das u boot sits as a bootloader Mar 07 05:34:49 and it would be nice if we would be able to utilise device's stock one Mar 07 05:36:26 There's been some work to make kexec() booting work (I think in the mukluk project). Mar 07 05:36:41 I don't know that it's widely tested yet. Mar 07 05:37:05 I think it's far from what is desired Mar 07 05:37:15 But for devices that need JTAG to populate the boot space, that approach is probably best. Otherwise it's hard for end-users to update their kernels. Mar 07 05:37:24 Baybal: By which audience? Mar 07 05:38:03 I think the best would be to utilise bootloaders supplied with device Mar 07 05:38:51 and moreover, most socs don't have nand boot logic and they use very tiny boot partitions on nors Mar 07 05:39:51 sometimes so small that things like dasuboot can't fit Mar 07 05:40:29 Baybal: I'm a fan of using bootloaders supplied with devices. Some just don't happen to support loading arbtrary kernels, and these need to be worked around. Mar 07 05:40:41 yes Mar 07 05:42:20 probably there are no way other than to have a set of custom bootloaders for every device Mar 07 05:43:32 Why? Mar 07 05:43:56 In the x86 world, there are about 8 common first-stage bootloaders, and *one* common second-stage bootloader. Mar 07 05:44:13 In the ARM world, there are about 4 common monolithic bootloaders. Mar 07 05:44:37 There exists no reason beyond lack of communication and cooperation that the same code can't work everywhere (that's kinda the point of portable code). Mar 07 05:45:08 just because of nand and nor differences for example Mar 07 05:47:02 That's just bootloader config. For example, the i.MX51 can boot from NOR, NAND, or SD, depending on the config with redboot. Mar 07 05:47:28 No reason we can't have per-board configs (or even per-install configs), but that doesn't mean we can't have only a few bootloaders. Mar 07 05:47:30 it's not a problem on devices with a few megabytes of boot flash, but in example on cell phones boot flash can be small as a few kilobytes Mar 07 05:49:07 persia & Baybal: are there relatively simple ways to have Ubuntu's ARMv7-A images start booting from NOR and shift to NAND? I'm hoping it is something which does not require custom USB images to alter. (A bit of a cop out, I know. :) ) Mar 07 05:49:23 jmc93739653: How do you mean "shift"? Mar 07 05:50:02 jmc93739653: Typically the monolithic kernel has to exist on some single device. No reason you can't do something like bootloader-on-NOR, kernel-on-NAND, rootfs-somewhere-else (I do) Mar 07 05:51:12 yes, we would probably end up doing this Mar 07 05:52:03 I think there would be no need in custom images, but would be need in custom kernels and bootloaders Mar 07 05:52:33 Baybal: No need for images? How does an install happen? Mar 07 05:53:16 persia: I had finished downloading an earlier Lucid i.MX515 image very late at night, about a month ago. I 'dd' the .img to an SDHC card. Didn't work (aah, ignorance!), but wanted to ask if the bootloader was a hard-dependency (RedBoot versus u-Boot, for example), or if it could be altered. Mar 07 05:53:58 jmc93739653: You can certainly alter it. I doubt you can use those SD images except on the dev boards they were designed to run on. Mar 07 05:54:07 just we need to get fs image to be on device flash, then we are free to boot our kernel as we wish Mar 07 05:54:07 I know they don't work on my NetWalker. Mar 07 05:54:34 Baybal: That's what the images are designed to do :) But sure, you don't need to use them. Mar 07 05:55:16 US visa declaration site is such a pain Mar 07 05:55:35 Baybal: I can alter the provided uBoot source & use the BSP supplied Linux kernel in the stead of the image's default. (I have no qualms about creating custom images.) Mar 07 05:56:00 yeah you can Mar 07 05:56:48 Paper forms was much more nicer... Mar 07 05:56:53 jmc93739653: The main tricky bit is that you might have to fiddle with flash-installer to properly install new kernels if you're using .deb format for kernel distribution. Mar 07 05:57:23 Baybal: I've been rather impressed at the large UX/workflow disparities between different governmental bodies' online softwares. Mar 07 05:57:23 jmc93739653: If you *do* have to fiddle, and you do so in a generic way that keeps other boards working, patches would be appreciated. Mar 07 06:00:01 The main target now is to get linux arm tree unified and not to have few thousands of forks for every chip Mar 07 06:00:07 persia: Awesome. It's nice having _real_ ARM kit. The ARMv7-A ISA revision, specifically. The performance improvements stemming from lithographic evolution is quite pleasing. Mar 07 06:00:38 Baybal: It's the only sane path forward, IMO. Mar 07 06:01:15 I think we need to take a couple steps with the kernels. Mar 07 06:01:18 Is linux-omap still a radically different branch than Linus' "vanilla" upstream? Mar 07 06:01:33 To me, the first step is to move from one-kernel-per-board to one-kernel-per-SoC Mar 07 06:01:43 Once there, moving to one-kernel-per-architecture gets easier. Mar 07 06:01:54 and for now I think we would be forced to have multiple kernels on image, like kernel-{broadcom,tegra,omap,msm,etc} Mar 07 06:02:09 jmc93739653: The code is getting closer, but there's still lots of limitations in terms of compiled artifacts. Mar 07 06:03:08 persia: Is #ubuntu-arm's topic information still up-to-date? I'd love to be of use. (I'm no expert [far, far from it], but it is always fun to dive head-first into a new area of expertise.) Mar 07 06:03:37 persia: I'm beginning to despair at the state of what appears to be _every_ ARM SoC's GPU's drivers. Mar 07 06:05:12 nVidia's binary blobs seem the least offensive, if only because their Linux x86-32 & x86-64 driver support is always in-tune and on-time. (Setting aside my ideological/legal misgivings.) Mar 07 06:05:14 the stock kernel can now work only on a handful of devices which were initially planed as completely open Mar 07 06:07:03 jmc93739653: I don't see anything specifically out of date in the topic, except that some of the wiki pages would benefit from a refresh (been on my TODO list for a very long time) Mar 07 06:07:50 jmc93739653: And more hands would certainly be welcome. The three areas that need the most help are more porting (see the FTBFS list), more porting (see the Thumb2 stuff), and testing. Mar 07 06:09:25 I need to get a FPGA device in the next year or two and start fiddling with fundamental GPU hardware implementation details. I'm hoping ARM's future ISA revisions will aid the use of pure CPU-driven graphics engines. (Multi-core & SIMD advances similar to Intel's Larrabee New Instructions [LRBni] and Advanced Vector Extensions [AVX], et cetera would help immensely. Mar 07 06:10:04 My gripe with nvidia is with the legacy stuff: Mar 07 06:10:07 Or get an ARM box with PCIe, and use any of the cards for which we have drivers :) Mar 07 06:10:10 and it would be nice to stick at least with armv7a with thumb, cache, new eabi and have neon as option Mar 07 06:10:11 All it ever does is segfault the X server. Mar 07 06:10:25 And then they keep updating it to *segfault* NEW X servers. =þ Mar 07 06:10:52 Baybal: The rumours I hear are that we'll be seeing that kind of stabilisation in future releases, but it largely depends on enough factors that I can't be sure. Mar 07 06:11:41 just I think there are no point to have support of anything older than cortex cores Mar 07 06:12:11 just because everything older simply is too slow Mar 07 06:13:16 Off topic: I noticed about ten weeks ago ARM announced certified Jazelle support for Android's Dalvik VM. So much for field of use restrictions! :) Mar 07 06:14:20 as i know dalvik doesn't use jazelle Mar 07 06:14:32 and simply have different bytecode format Mar 07 06:14:57 Baybal: I've been procrastinating too much reading the reference docs for ARMv6 (i.e. ARM11) and ARMv7 (Cortex-??) Mar 07 06:15:53 armv7a=cortex-a{5,8,9} Mar 07 06:16:21 Hmm, there's some confusing naming. Mar 07 06:16:26 so ARM11 is weaker than ARM7? Mar 07 06:16:40 about 2 times Mar 07 06:16:48 for cortex a8 Mar 07 06:16:56 1.5 for a5 Mar 07 06:16:56 Baybal: lucid doesn't support anything less than ARMv7+vfp+thumb2 Mar 07 06:17:11 Baybal: Really? I could have sworn ARM and the OHA got all lovey during their Solution Center for Android (ARM SCA). Mar 07 06:17:24 And I doubt it works reliably on ARMv7 != ARMv7a Mar 07 06:18:15 DanaG: ARMv7 refers to the microarchitectural guarantees for ARMv7 instruction set architecture compliant chips. Mar 07 06:18:47 DanaG: The tell is the "v" between ARM and the numbers following it. Mar 07 06:19:06 just armv7 cores other armv7a are targeted not for consumer electronics Mar 07 06:19:34 ah, so is Cortex just a marketing name? Mar 07 06:19:36 like m and r for something like dishwashers Mar 07 06:19:44 no Mar 07 06:19:57 cortex just means armv7* Mar 07 06:19:57 Baybal: Are you *sure* you don't want to run Ubuntu on your dishwasher :) Mar 07 06:20:11 (but more seriously, yeah, ARMv7a is the only target) Mar 07 06:20:24 I just want it to play nice on my v7a phone Mar 07 06:20:51 we can run netbsd on toasters and dishwashers =D Mar 07 06:21:22 DanaG: An ARM1136JF-S, however is a specific ARMv6 compliant CPU design. Mar 07 06:21:32 so I think some of developers here should propose shift from v7 to v7a Mar 07 06:21:54 Baybal: There is already an assumption of v7a, I believe. Mar 07 06:22:17 Or rather, I don't think there's any available optimisation to be gained by making changes to more aggressively not support 7m or 7r devices. Mar 07 06:22:25 just gcc have different -march values Mar 07 06:22:35 And I know that there's almost no testing done for anything other than 7a Mar 07 06:23:00 Baybal: Precisely which changes to gcc defaults would you recommend? Mar 07 06:23:37 and I suspect that setting -march to other than armv7a greatly limits gcc in selection of instructions Mar 07 06:23:40 I thought ARMv7-A was a partial superset of ARMv7 µArch; including ARMv7-M and ARMv7-A (dropping the real-time guarantees found in ARMv7-R cores). Mar 07 06:24:05 there are some instruction set differences Mar 07 06:24:09 Lucid is still using GCC 4.4.x, yes? Mar 07 06:24:32 (GCC-4.5 still being held up by libgcc licensing issues?) Mar 07 06:25:26 Thanks all for the lively channel, by the way, this is great fun. :) Mar 07 06:25:38 I think it's also that lucid is in a test-phase preparing for release. Mar 07 06:25:56 so I hope somebody would ensure that gcc is set for armv7a+thumb only Mar 07 06:26:54 persia: the toolchain has to be locked down by now in the release schedule. Debian Testing couldm Mar 07 06:28:00 couldn't have moved that fast. (I know I'm presuming here, so there's definitely a margin of error..) Mar 07 06:28:52 jmc93739653: We usually make best efforts to lock down at least the major version of the toolchain packages in the first month of each release cycle. Otherwise it's toohard to keep up with 20,000 packages. Mar 07 06:30:39 persia: Agreed, if there isn't a hard deadline at some point, releases couldn't adhere to any rational schedule. Mar 07 06:31:16 Precisely :) Mar 07 06:31:19 persia: Debugging a toolchain _and_ any given kernel, library, application? That's asking for pain. Mar 07 06:33:31 Right, so we tend to freeze toolchain (except for bugfixes for known issues) early, freeze kernel version early (although lots of patches and bugfixes continue), and focus on applications. Mar 07 06:33:51 We freeze the application and library versions (mostly) around the middle of the release cycle, and then just try to hammer out all the bugs. Mar 07 06:34:05 We've yet to be completely successful, but it works as a model for our release schedules. Mar 07 06:36:34 and also gcc doesn't set other necessary flags by default, so ensure things like -mthumb-interwork -mthumb -mtpcs-frame -mcallee-super-interworking Mar 07 06:37:14 Baybal: Are you sure these aren't being set by Ubuntu gcc by default? This sounds a lot like a conversation we had at UDS where it was decided to set these by default. Mar 07 06:37:29 don't know Mar 07 06:40:40 Baybal: Please try (qemu if you don't have hardware). I think most of your concerns have been addressed. Mar 07 06:41:00 And I think the rest are intersting, but need to be separated and reviewed individually, after comparison with the current defaults. Mar 07 06:41:19 can you give a link to image? Mar 07 06:42:21 Which kind? We have Ubuntu Netbook, Kubuntu Netbook, and Ubutu Server. Ubuntu Netbook gets the most testing. Mar 07 06:42:43 Lots of folk use rootstock to generate rootfss to meet their needs. Mar 07 06:43:05 I mean arm image Mar 07 06:44:04 Baybal: So do I :) Which flavour? Mar 07 06:44:25 netbook Mar 07 06:44:45 http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-live/current/ always points at the most recent image. Mar 07 06:45:02 It might not work perfectly (depending on the state of the packages when it was constructed). Mar 07 06:45:20 ok I would check after I finish downloading movie Mar 07 06:45:24 Also note that they are currently images for specific SoCs : you may have to extract the rootfs if you don't have one of those SoCs. Mar 07 06:45:30 Baybal: Thanks! Mar 07 06:46:22 have you any experience with a9 boards? Mar 07 06:46:34 Not I. Mar 07 06:47:01 * jmc93739653 so wishes he had ahold of an A9 MPcore. Mar 07 06:47:43 also it would be interesting if we are going to run it on a5 machines if there would be any other than cellphones Mar 07 06:48:03 a5? Mar 07 06:48:07 yes Mar 07 06:49:33 smartphone market are probably going to separate on a8 for high end devices and a5 retaining current arm11 position Mar 07 06:49:43 What is a5? Mar 07 06:49:49 * persia has not previously encountered the term Mar 07 06:49:53 arm cortex-a5 Mar 07 06:50:03 What instruction set does that support? Mar 07 06:50:09 v7a Mar 07 06:50:24 Oh, cool. No worries then: it ought just work. Mar 07 06:50:43 it's going as a change for arm11 Mar 07 06:50:45 If it's a low-end design, I'd expect to see it also in NAS boxes, home routers, etc. Mar 07 06:51:05 probably it's mostly for cellphones Mar 07 06:51:34 as it's our of order, neon, but not superscalar Mar 07 06:51:49 Is it also cheaper than a8 or a9? Mar 07 06:51:54 much more Mar 07 06:52:16 I'm rather bewildered as to why ARM didn't just roll a completely in-house, no third-party IP graphics chip for their Mali line. They'd have pragmatists ditching ImgTec's PowerVR & Qualcomm Adreno graphics cores ASAP. Mar 07 06:52:21 Then yeah, I definitely expect to see it in NAS, home routers, watches, etc. Mar 07 06:52:28 but I haven't yet seen any soc based on it with my own eyes yet Mar 07 06:52:47 jmc93739653: Ask the same question for any CPU design firm for any architecture :) Mar 07 06:53:14 Baybal: I _knew_ the A9 had superscalar OoOE. I tried finding primary sources a few months back and no joy. Mar 07 06:54:12 they license mali core just as they do with cpu cores Mar 07 06:56:47 I do find it rather interesting ARM had the benefit of implementing decades old microarchitecture CPU improvements, as process nodes and thermal budgets permit, where as Intel has to strip out the power-intensive features and invest deeply into more and more advanced fabrication nodes. I'm sure IBM chuckled at Intel during x86's evolution. Mar 07 06:56:59 a5 don't have superscalar execution because it's thought that for crunching big amounts of data the chip would use various dsps and accelerators Mar 07 06:58:34 the reason is you don't have to have ooo, superscalarity, mmu and fpu to drive dishwashers Mar 07 06:59:27 Well, depends on the dishwasher :) Mar 07 07:00:52 but anyway a5 is going to be faster than arm11 Mar 07 07:01:31 Baybal: Do you think there are any serious chances ARM would work with the FSF (akin to the Linux Driver Project) to improve [L]GPL toolchain support for their designs? (Firms deviating from standard IP core offerings would probably not elect to do this) Mar 07 07:01:57 jmc93739653: toolchain isn't the issue at this point. It's all kernel + drivers. Mar 07 07:02:03 Baybal: Nice. I had read the A5 was going to be a dog. Mar 07 07:02:28 comparatively, surely, but for most applications that oughtn't matter. Mar 07 07:03:14 We're arguing about different things. Mar 07 07:03:20 * jmc93739653 facepalms. persia: you are correct re: kernel & drivers. I conflated toolchain & driver issues. I'm going to need to sleep soon. Mar 07 07:03:23 I completely agree that you can't make a public bug private. Mar 07 07:03:32 ECHANNEL :) Mar 07 07:25:27 Apologies for those who may have misunderstood. My comment "ECHANNEL" was about *my* traffic being in the wrong place. Mar 07 07:25:33 Everyone else should feel free to continue. Mar 07 07:25:48 I just happened to set the wrong focus when having a separate conversation. Mar 07 07:29:15 I'm happy I haven't entered my IRC passcode in a channel; plain-text, naturally. Mar 07 07:30:54 I've made that mistake :) I've also pasted by SSH passkey, my user password, my GPG passkey, etc. Mar 07 07:31:10 Most of these can be resolved by quick action and judicious choices of passwords, but ... :) Mar 07 07:48:55 There's always the eight year old password that I use when I'm dog-tired that I know I'll blurt out some day _juuust_ as the search engine crawlers scan wherever I leaked it. Mar 07 07:49:08 heh. Mar 07 10:02:28 This might be blasphemy here, but I'm wondering how hard it would be to recompile the Ubuntu Lucid for armv5t. Mar 07 10:04:56 might take you some months (depending onh the amount of pacages you want) and a buildd setup ... and indeed you would need to fix breakage you find along the go Mar 07 10:06:04 Hmm, it's probably not worth it then. I was hoping there wasn't a huge delta from Debian (which still works on armv5). Mar 07 10:08:44 if you want v5 better go with debian Mar 07 10:10:27 or stick with jaunty :) Mar 07 10:12:47 Debian is ARMv4, not ARMv5. Mar 07 10:13:14 which is 95% irrelevant Mar 07 10:13:35 But it's not that much *code* delta, it's just toolchain and compile delta. There's no reason one can't construct an ARMv5 repo, except nobody has (recently) invested the time into doing so. Mar 07 10:13:52 suihkulokki: Hrm? Aren't there a bunch of devices that aren't ARMv5 that Debian supports? Mar 07 10:14:31 persia: I mean ARMv4 vs ARMv5 Mar 07 10:15:10 I thought that there was some stuff that needed ARMv4. Mar 07 10:15:32 openmoko, no ? Mar 07 10:15:55 I thought openmoko was almost-but-not-quite ARMv4 and needed special hacks. Mar 07 10:16:13 * persia may well be misinformed, but would appreciate correctyion Mar 07 10:16:14 .... Mar 07 10:17:11 * ogra_cmpc sighs about qemu ... Mar 07 10:17:35 * amitk is surprised there is not editor in our initramfs! Mar 07 10:17:41 *no Mar 07 10:17:42 so i went back with the qemu-system-arm binary to 0.11.1 and still see the hangs Mar 07 10:17:49 amitk: Why does one need one? Mar 07 10:17:52 amitk, there is ed :) Mar 07 10:17:59 and busybox-sed Mar 07 10:18:13 persia: to edit files if you've messed your sysstem? Mar 07 10:18:27 ogra_cmpc: no ed either Mar 07 10:18:32 and you should be able to chroot into /root and copy back and forth files Mar 07 10:18:56 ogra_cmpc: what if /root is the problem ;) Mar 07 10:19:03 amitk: There's nothing that you can't do with busybox sed. Users who want a good interface are encouraged to boot something else and chroot :) Mar 07 10:19:05 i.e. copy the file you want to change into /root ... chroot ... edit, exit, copy back Mar 07 10:20:07 amitk, hmm, you could create a vim hook for initramfs-tools that just copy_execs vim Mar 07 10:20:28 indeed if your system is already unbootable you are screwed Mar 07 10:21:58 amitk: From your preboot environment can you mount anything? That's often a good way to get to executables. Mar 07 10:23:39 http://pastehtml.com/view/5tp3b34.txt Mar 07 10:24:14 rootstock failed Mar 07 10:24:16 persia: yeah, I can get to break=init. So chroot should probably work Mar 07 10:24:17 http://pastehtml.com/view/5tp3b34.txt Mar 07 10:26:42 aaron_liu, what release are you trying to build and whats your host release ? Mar 07 10:29:05 the latest release Mar 07 10:29:26 lucid on lucid ? Mar 07 10:29:47 sudo apt-get install rootstock Mar 07 10:30:01 on a lucid system ? Mar 07 10:30:11 (10.04 dev) Mar 07 10:30:33 (use lsb_release -a to find out if you dont know) Mar 07 10:31:10 Distributor ID: Ubuntu Mar 07 10:31:18 Description: Ubuntu 9.10 Mar 07 10:31:22 ah Mar 07 10:31:26 9.10 Mar 07 10:31:49 and what are you trying to build ? (did you ude the -d option for rootstock ?) Mar 07 10:32:03 i have update to 9.10 from 9.04 Mar 07 10:32:17 no Mar 07 10:32:46 hmm, that should work ... it does for others .... Mar 07 10:33:13 you can easily modify the rootstock script in /usr/bin/rootstock though Mar 07 10:33:17 http://bazaar.launchpad.net/~project-rootstock-developers/project-rootstock/trunk/revision/53 Mar 07 10:33:28 thats the change you need Mar 07 10:35:16 http://code.google.com/p/chromium/wiki/LinuxChromiumArm Mar 07 10:35:36 i just follow the steps to compile chrome for arm Mar 07 10:37:26 yes, that should wor Mar 07 10:37:28 k Mar 07 10:41:53 but i don't know where i should to modify Mar 07 10:42:14 but i don't know where i should to modify /usr/bin/rootstock Mar 07 10:42:44 open it in an editor (with sudo) then look for the line that mounts /dev/pts Mar 07 10:42:59 relatively far at the bottom of the script Mar 07 10:43:13 before the mount command you add: Mar 07 10:43:19 mkdir -p /dev/pts Mar 07 10:43:36 then save the file Mar 07 10:48:20 E486: Pattern not found: mounts \/dev\/pts Mar 07 10:49:06 mount Mar 07 10:49:09 not mounts Mar 07 10:49:16 E486: Pattern not found: mount \/dev\/pts Mar 07 10:49:41 just look for \/dev\/pts Mar 07 10:51:01 yeah found it Mar 07 10:51:13 follow echo "I: Starting basic services in VM" Mar 07 10:51:50 but how to do that next Mar 07 10:52:21 do i need mkdir -p /proc / Mar 07 10:52:46 * lool just discovers about slind.org; apparently a wider set of tools than just emdebian, with some corporate backing Mar 07 10:53:00 Not that active in the last year though Mar 07 10:53:38 ogra_cmpc Mar 07 10:54:05 and then i what should i do Mar 07 10:54:20 and then what should i do Mar 07 10:54:23 add the line i gave you above Mar 07 10:54:34 mkdir -p /dev/pts Mar 07 10:54:40 yeah ,i have down Mar 07 10:54:46 directly above the line where /dev/pts gets mounted Mar 07 10:55:09 how to do next ? Mar 07 10:55:21 save the file Mar 07 10:55:29 then run it again Mar 07 10:55:29 yeah Mar 07 10:55:48 should work now Mar 07 10:56:34 run again , how to run Mar 07 10:56:38 ? Mar 07 10:57:14 i follow the steps http://code.google.com/p/chromium/wiki/LinuxChromiumArm Mar 07 10:57:45 right Mar 07 10:57:53 Building a rootfs section command Mar 07 10:58:16 yes, do that Mar 07 10:58:31 sudo rootstock --fqdn beagleboard --login ubuntu --password temppwd --imagesize 2G --seed xfce4,gdm,pkg-config,python,perl,g++,bison,flex,gperf,libnss3-dev,libgtk2.0-dev,libnspr4-0d,libasound2-dev,libnspr4-dev,libgconf2-dev,libcairo2-dev,libdbus-1-dev,libstdc++6-4.4-dev,libexpat1-dev,libxslt1-dev,libxml2-dev,libbz2-dev --dist karmic Mar 07 10:59:03 but it need long time to download packages and unzip its Mar 07 10:59:13 yes, thats normal Mar 07 11:00:09 i think there should be a good method to avoid it Mar 07 11:00:18 avoid what ? Mar 07 11:00:26 download pkgs Mar 07 11:00:49 use an apt proxy Mar 07 11:00:58 * ogra_cmpc uses approx Mar 07 11:01:08 or a local package mirror Mar 07 11:02:17 i mean if each time runs the system .i need so long time to download pkgs Mar 07 11:02:50 yes, a package proxy or local mirrir help with that Mar 07 11:04:01 where i can got the rootfs Mar 07 11:04:07 where i can got the rootfs in he end Mar 07 11:04:11 where i can got the rootfs in the end Mar 07 11:04:29 the script tells you where it stored the tarball Mar 07 11:05:36 BUILDDIR=$(mktemp -d) Mar 07 11:06:01 (similar to how it told you about the logfile when your build failed before) Mar 07 11:09:27 lool, so i went backwards through the binary packages replacing qemu-system-arm ... i can even reproduce the hang with the two karmic versions ... Mar 07 11:09:48 (which i cant on a krmic system) Mar 07 11:10:52 root@aaron-ubuntu:/tmp/tmp.bypTc6Upgl/tmpmount# ls Mar 07 11:11:04 i'm starting to wonder if its an issue with the hostkernel?host system Mar 07 11:11:37 root@aaron-ubuntu:/tmp/tmp.bypTc6Upgl/tmpmount# ls Mar 07 11:11:38 debootstrap lost+found var Mar 07 11:11:58 it's the fsroot ? Mar 07 11:12:15 its the tmeporary dir Mar 07 11:13:33 is it /tmp/tmp.bypTc6Upgl/qemu-armel-201003071903.img ? Mar 07 11:14:53 no, it is what comes out in the end Mar 07 11:15:17 you just point to random pieces that are used to assemble the final thing Mar 07 11:15:36 just wait until its done, i tells you where it copies the final tarball Mar 07 11:17:05 Err build-essential rebuild as part of mass-thumb2 rebuilds? :) Mar 07 11:17:24 seems it was on the list :) Mar 07 11:17:38 likely a false positive Mar 07 11:18:41 LANG=C tar czvf ../armel-rootfs-$STAMP.tgz . >>$LOG 2>&1 Mar 07 11:18:41 i think the list criteria was only: not uploaded and not imported from debian during lucid Mar 07 11:22:22 ogra_cmpc: And some arch: any package I hope Mar 07 11:22:38 I: Retrieving ..... Mar 07 11:22:47 I: Validating..... Mar 07 11:23:09 lool, i dont know, i didnt assemble that list, i think it comes from some script from doko Mar 07 11:24:40 intrestig, build-essential is any ??? Mar 07 11:24:44 yes Mar 07 11:24:49 because the deps differ on architectures Mar 07 11:24:50 i thought thats only a metapackage Mar 07 11:24:53 ah Mar 07 11:25:32 so long time to waste each time i runs rootstock for download pkgs ,why it cannot connot runs as begin as prevoius time Mar 07 11:26:09 so long time to waste each time i runs rootstock for download pkgs ,why it cannot runs begin as prevoius time Mar 07 11:26:37 because the packages are individually selectable ... it doesnt know in the beginning which dependencies are needed Mar 07 11:27:21 it would be possible to generate the dependency chain in advance with germinate... but its unlikely that this would be any faster Mar 07 11:27:56 ok,i known Mar 07 11:28:50 the lucid (10.04) version of rootstock has a cache function but you need at least one successfull run and you can only do the same run again subsequently Mar 07 11:29:05 who have done for chrome in the arm ubuntu-arm platfom Mar 07 11:29:54 https://launchpad.net/ubuntu/+source/chromium-browser Mar 07 11:30:34 there is a team https://launchpad.net/~chromium-team Mar 07 11:30:39 it's not for arm Mar 07 11:31:36 sure it is Mar 07 11:32:07 see the "builds" links on the first page i posted Mar 07 11:37:53 it desn't show it for arm Mar 07 11:38:26 it does for me Mar 07 11:42:34 http://ppa.launchpad.net/chromium-daily/ppa/ubuntu/dists/karmic/main/binary-armel/Packages.bz2 Mar 07 11:42:42 it for arm ? Mar 07 11:49:20 binary-armel is for arm, yes Mar 07 11:49:48 note that there are no chromium packages for karmic ... chromium is in the archive for lucid though Mar 07 11:52:49 bin/installer: line 15: udevd: command not found Mar 07 11:55:06 udevd is installed in the first stage, did zou change any other stuff or fiddle in the directories you posted above during the build ? Mar 07 11:55:16 s/zou/you/ Mar 07 11:57:11 http://pastebin.com/vZhM9ddA Mar 07 11:58:05 line 433 is your problem Mar 07 12:01:10 is the qemu-arm-static package installed on your system ? seems like your machine cant execute armel binaries Mar 07 12:02:19 (i guess that also caused the /dev/pts issue before) Mar 07 12:03:15 mkdir -p /dev/pts Mar 07 12:03:23 mount -t proc proc /proc Mar 07 12:03:23 no Mar 07 12:03:30 mount -t sysfs sys /sys Mar 07 12:03:38 mount -t devpts devpts /dev/pts Mar 07 12:03:46 udevd --daemon & Mar 07 12:03:53 see your first paste, it has exactly the same error as line 433 in your second paste Mar 07 12:04:36 but how should i do Mar 07 12:04:38 chroot: cannot run command `debootstrap/debootstrap': Exec format error Mar 07 12:05:07 your system isnt properly set up, the qemu-arm-static package cant execute armel binaires Mar 07 12:05:33 the /dev/pts issue was only a subsequent error Mar 07 12:09:07 http://pastebin.com/gfYdkiiY Mar 07 12:10:10 cack your installation of qemu-arm-static ... pasting random lines from the rootstockj script doesnt help Mar 07 12:10:40 your system apparently cant execute armel binaries Mar 07 12:11:26 i think line num 611 udevd --daemon & cause error Mar 07 12:11:30 no Mar 07 12:11:54 again ... your qemu-arm-static package is not properly installed Mar 07 12:12:01 fix that and it will work Mar 07 12:12:31 it has nothing to do with udev or /dev/pts Mar 07 12:12:37 but where i can find qemu-arm-static Mar 07 12:13:03 it is a dependency fo rootstock and should be installed already Mar 07 12:13:09 but something is wrong with it Mar 07 12:13:43 are you using an ubuntu kernel on your machine ? Mar 07 12:13:57 yeah Mar 07 12:13:58 qemu-arm-static uses the binfmt support of the ubuntu kernel Mar 07 12:14:37 from rootstock-201003071903.log Mar 07 12:15:00 first line Formatting '/tmp/tmp.bypTc6Upgl/qemu-armel-201003071903.img', fmt=raw size=2147483648 Mar 07 12:15:26 bu i couldn't find the file '/tmp/tmp.bypTc6Upgl/qemu-armel-201003071903.img' Mar 07 12:15:28 yes ? Mar 07 12:15:43 no, it gets removed during build Mar 07 12:15:55 or rather at the end of the build Mar 07 12:16:01 its a temporary file Mar 07 12:16:21 but how to do that for me Mar 07 12:17:11 what ? Mar 07 12:17:24 how i should to do Mar 07 12:18:16 what can i do Mar 07 12:18:32 fix your qemu-arm-static install Mar 07 12:19:13 apt-get install qemu-arm-static Mar 07 12:19:14 ? Mar 07 12:19:31 try: sudo apt-get install --reinstall qemu-arm-static Mar 07 12:19:36 that will force a reinstall Mar 07 12:20:06 also try sudo /etc/init.d/binfmt-support restart Mar 07 12:20:51 have down Mar 07 12:21:11 also have a look at /proc/sys/fs/binfmt_misc/ Mar 07 12:21:19 there should be a file called arm in there Mar 07 12:23:25 binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev) Mar 07 12:23:32 when i mount Mar 07 12:23:34 binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev) Mar 07 12:23:42 right ? Mar 07 12:23:45 no Mar 07 12:23:52 also have a look at /proc/sys/fs/binfmt_misc/ Mar 07 12:23:53 there should be a file called arm in there Mar 07 12:24:17 look in the directory Mar 07 12:25:13 root@aaron-ubuntu:~# ls /proc/sys/fs/binfmt_misc/ Mar 07 12:25:26 arm cli python2.4 python2.5 python2.6 register status Mar 07 12:26:01 lool, oh, looking at that in lucid i seem to have founda bug :) the binfmt handler for armel points to qemu-arm-static instead of qemu-armeb-static :) Mar 07 12:26:12 err Mar 07 12:26:20 the binfmt handler for armeb i mean Mar 07 12:26:34 aaron_liu, that looks good Mar 07 12:26:50 ogra_cmpc: Um, everything looks right to me. Are you sure? Mar 07 12:27:11 ogra@osiris:~$ cat /proc/sys/fs/binfmt_misc/qemu-armeb|grep interpreter Mar 07 12:27:11 interpreter /usr/bin/qemu-arm-static Mar 07 12:28:16 Oh, indeed. Mar 07 12:28:23 persia, given that lool enabled a specific qemu-armeb-static binary build i'd expect the binfmt handler to use it :) Mar 07 12:28:27 That package has had *lots* of uploads recently. Just do it again :) Mar 07 12:29:01 * persia needs to update mk-sbuild and pbuilder-dist now Mar 07 12:29:19 i doubt most of the handlers work though Mar 07 12:29:36 ppc might with luck ... Mar 07 12:29:37 So what? Mar 07 12:29:46 i wouldnt rely on them Mar 07 12:29:55 The important bit isn't whether they work, but whether the interfaces are sane. Mar 07 12:29:57 armel is the only tested one atm Mar 07 12:30:00 I don't intend to do so. Mar 07 12:30:13 But I'd rather unpack the special-case stuff. Mar 07 12:30:21 ah, i thought you wanted to make the builder tools point to them Mar 07 12:30:28 I did. Mar 07 12:30:32 Still do, actually. Mar 07 12:30:45 Or rather, I want to not special-case arm in the tools. Mar 07 12:31:16 ah Mar 07 12:31:45 * ogra_cmpc still tries to track down the qemu hang Mar 07 12:31:49 lool: When you have a chance, could you share your strategy? I'd be happy to help with various bits, but don't want to duplicate work. Mar 07 12:31:53 i dont get why it doesnt happen in karmic Mar 07 12:32:27 i use the karmic qemu-system-arm binary and my old qemu kernel now ... Mar 07 12:32:33 but it still hangs Mar 07 12:32:46 * ogra_cmpc replaces qemu-img with dd now Mar 07 12:40:49 root@aaron-ubuntu:~# cat /proc/sys/fs/binfmt_misc/qemu-armeb|grep interpreter Mar 07 12:40:55 cat: /proc/sys/fs/binfmt_misc/qemu-armeb: No such file or directory Mar 07 12:41:40 arm cli python2.4 python2.5 python2.6 register status in the /proc/sys/fs/binfmt_misc dir Mar 07 12:42:06 ls /proc/sys/fs/binfmt_misc Mar 07 12:42:19 arm cli python2.4 python2.5 python2.6 register status Mar 07 12:43:55 aaron_liu, yes i was not talking to lool about lucid, you rin karmic there only the arm binfmt hook exists Mar 07 12:43:57 aaron_liu: qemu-armeb is brand new: you only care about /proc/sys/fs/binfmt_misc/arm Mar 07 13:28:54 hrm, dd didnt help either, i dont get what else could be wrong Mar 07 13:37:08 ogra_cmpc, persia: I copied the other binfmts from Debian; it might be a bug I copied over (armeb versus arm) Mar 07 13:37:26 persia: Strategy on which part? I also would like to remove arm-specific handling Mar 07 13:37:49 persia: I had in mind to rename build-arm-chroot to build-qemu-chroot or something along these lines; perhaps qemu-debootstrap Mar 07 13:38:29 I started some wiki pages, but these are too rough at the moment, I was too busy to finish them last week Mar 07 13:39:59 Laibsch: heya Mar 07 13:40:07 Laibsch: Thanks for your emails; will check it out Mar 07 13:40:09 hey! Mar 07 13:40:13 great Mar 07 13:40:51 I have a few stupid questions Mar 07 13:40:55 Is armv4, armv5, etc. akin to i386, i486, i586, etc? Mar 07 13:41:09 Kind of Mar 07 13:41:29 It's usually more complex than that because there are sub-ISAs associated with armvN families Mar 07 13:41:35 yes Mar 07 13:41:38 It's a big mess Mar 07 13:41:39 For instance armv5 only comes in Thumb flavors Mar 07 13:41:49 And then Thumb itself was extended multiple times Mar 07 13:41:50 and I so far successfully avoided to understand it Mar 07 13:42:21 and on an orthogonal scale, you have the FPU ISA; 387 or SSE for Intel, and either a lot of old stuff on ARM or VFP with associated versions Mar 07 13:42:32 and optional NEON or other VFP extensions Mar 07 13:43:12 OK, so it's not linear like in the Intel case, but lots of different things that may or may not be supported (with the later CPUs generally supporting more, of course) Mar 07 13:43:15 ? Mar 07 13:43:45 There are some "implications" in the case of intel code as well, but it's more backwards compatible than arm is Mar 07 13:43:54 OK Mar 07 13:43:56 thanks Mar 07 13:44:17 I guess that is sufficient for me for now as far as the CPU variations are concerned Mar 07 13:44:21 what determines the minimum level of CPU support a binary needs? Is that a flag given to gcc, determined by the host on which it runs or something else entirely? Mar 07 13:44:33 lool, ++ on qemu-debootstrap ... Mar 07 13:45:00 Laibsch: You mean at build time? Mar 07 13:45:34 well, both Mar 07 13:45:48 for example, can a very recent arm cpu output armv4 code? Mar 07 13:45:53 Laibsch: It's mostly the flags you pass to gcc, but it can also be what binaries you combine together Mar 07 13:45:56 can I force it to output armv4? Mar 07 13:46:01 OK Mar 07 13:46:03 Laibsch: hardware has nothing to do with build output Mar 07 13:46:09 so, it's got nothing to do with the compile host Mar 07 13:46:11 Since you can cross-compile arm from i386 Mar 07 13:46:12 OK, good Mar 07 13:46:26 Well, I want to avoid cross-compilation Mar 07 13:46:58 lool: I like the qemu-debootstrap name. Mar 07 13:46:59 I want to use all the debian-goodies out there Mar 07 13:47:10 that are generally not cross-compile-aware Mar 07 13:48:36 Laibsch: If you're running a Debian or Ubuntu armel userspace, it might be able to output binaries using a different target architecture than what Debian or Ubuntu targets, but you have to keep in mind that your binary might get linked to stuff such as libgcc or of course runtime libs such as libc Mar 07 13:48:38 lool: Do you need help with qemu-debootstrap, or are you already making progress there? The pbuilder-dist and mk-sbuild changes I'm confident about doing myself. qemu-debootstrap needs a complete rewrite of build-arm-chroot (proper options handling for one). Mar 07 13:48:42 In which case you need to rebuild these Mar 07 13:48:58 persia: I can do it I guess Mar 07 13:49:12 lool: that's kind of the idea Mar 07 13:49:22 I understand Ubuntu does not support older arm CPU Mar 07 13:49:34 The devices I currently own are all armv5te max Mar 07 13:49:37 lool: Up to you. I don't mind doing it if you've got other stuff (as you've already done most of the heavy lifting) Mar 07 13:50:32 ogra_cmpc: Do you care about the contents of qemu-debootstrap as long as it's call-compatible for rootstock? Mar 07 13:50:47 * ogra_cmpc wonders what else to look for to track down the hang ... i ruled out qemu-system-arm, the kernel, qemu-img Mar 07 13:51:04 lool: I intend to compile the binaries elsewhere and then work out the kinks you mentioned (although I will likely hit more than enough bumps where I have no idea how to smooth them out) Mar 07 13:51:12 persia, rootstock doesnt even use the script :) Mar 07 13:51:46 ogra_cmpc: Oh. Didn't it used to do that? Mar 07 13:51:47 it still does a debootstrap --foreign ... all it uses is qemu-arm-ststic to chroot into the rootfs for the second stage run Mar 07 13:52:01 Aha. Then you don't care at all. Mar 07 13:52:03 persia, no, because there is no qemu-arm-static in jaunty Mar 07 13:52:08 Right. Mar 07 13:52:17 in jaunhty it does the second stage in a VM Mar 07 13:52:26 which is horribly slow Mar 07 13:52:40 lool: I should have time to work on this on Tuesday, so I'll take a swing if you haven't first. I want to get the updates to u-d-t in before betafreeze. Mar 07 13:59:18 heh Mar 07 13:59:24 * ogra_cmpc just had a weird idea Mar 07 14:00:11 i wonder if it would work to run a VM, export proc through nbd and mount that inside a chroot Mar 07 14:10:33 hmm, i suspect /proc/self etc wouldnt work Mar 07 14:10:45 http://ograblog.wordpress.com/2009/07/18/juggling-your-arms-in-karmic-and-no-more-excuses/ I hope this does what I've been looking for Mar 07 14:10:56 eFfeM1: that may be interesting for your as well ^^^ Mar 07 14:11:00 -r Mar 07 14:11:55 Laibsch, works for everything but mono stuff Mar 07 14:12:14 first thing I want to test is scim/uim/ibus Mar 07 14:12:18 then anki ;-) Mar 07 14:12:35 if I go wild, I'll have a look at compiling opie Mar 07 14:12:43 heh Mar 07 14:13:29 but basically, it's more about getting used to ubuntu-arm Mar 07 14:13:38 need to get my feet wet Mar 07 14:14:47 http://code.google.com/p/chromium/wiki/LinuxChromiumArm Mar 07 14:15:15 does i need the cross-compile Mar 07 14:15:18 ? Mar 07 14:15:40 for build the rootstock ? Mar 07 14:15:54 no Mar 07 14:15:55 does i need the cross-compile for build the rootstock ? Mar 07 14:16:04 no need ? Mar 07 14:16:13 no Mar 07 14:16:41 Get:289........... Mar 07 14:16:48 right/ Mar 07 14:16:58 right ? this time ? Mar 07 14:17:16 looks like its downloading packages in the VM Mar 07 14:17:44 but how long it would be Mar 07 14:19:10 just wait, it takes a while Mar 07 14:19:26 great Mar 07 14:19:42 thank for ur kind and help Mar 07 14:19:52 youre welcome Mar 07 14:23:03 ogra_cmpc witch chip u used Mar 07 14:23:10 ogra_cmpc witch arm chip u used Mar 07 14:23:45 freescale imx51 and marvell dove ... i also have an old begleboard Mar 07 14:24:15 I use th tcc8900 Mar 07 14:25:10 i down't know if can runs Mar 07 14:25:18 i down't know if it can runs Mar 07 14:26:45 it can run karmic (9.10) but not lucid (10.04) Mar 07 14:28:30 what 's it take room of ur ubuntu-os for arm Mar 07 14:29:00 with chromium ? Mar 07 14:29:16 that really depends what kind of desktop you run Mar 07 14:29:17 i think it need 4G flash at least Mar 07 14:29:48 i just want to run smallest sys Mar 07 14:29:52 i think with LXDE you can run in around 1G Mar 07 14:30:00 probably 2G Mar 07 14:30:04 never tried it Mar 07 14:30:45 it's include the x-11 it takes to much room Mar 07 14:31:18 X should only take 1-200MB Mar 07 14:32:10 it's include the x-11 it takes too much room,and if who port the chromium browser to the gtk+dfb,i think it so great challage Mar 07 14:34:45 persia: First pass http://paste.ubuntu.com/390382/ Mar 07 14:34:48 Untested yet Mar 07 14:37:34 lool, why die if you dont need qemu, just switch silently to std debootstrap Mar 07 14:37:42 ogra_cmpc: Just not implemented yet Mar 07 14:38:09 ah Mar 07 14:38:16 In particular, this should also reject biarch; using qemu-i386 isn't a good idea on amd64 Mar 07 14:39:05 heh, yeah Mar 07 14:41:58 what's the difference between lucid with Karmic ? Mar 07 14:42:07 6 months Mar 07 14:42:35 what's the difference between lucid with Karmic ?i am beganner of ubuntu Mar 07 14:44:41 who can tell me the difference Mar 07 14:45:44 Laibsch: thanks for the link Mar 07 14:48:29 Laibsch: Usually you don't reuse the toolchain to do rebuilds but use a different one unless you're just changing feature flags of the toolchain; if you're going to rebuild for another arch, it's best to rebuild the toolchain (it's part of the list of packages anyway, and you want to make sure that the rebuilt packages are using the new toolchain) Mar 07 14:49:18 lool, so, my hang seems to be related to imagesize ... if i use 1G all the unpacking gets through, if i use something like 4G i get the hang, do you know if there is any limitation in qemu causing that ? Mar 07 14:49:35 lool: hm, you kind of lost me here. Mar 07 14:50:07 ogra_cmpc: You could try using a 4G image with a small block size Mar 07 14:50:17 What I'm trying to do is get something set up so that I can compile packages from the debian archives for use on an arm device Mar 07 14:51:00 Laibsch: For instance if you rebuild with e.g. --no-stack-protector, you don't need to rebuild the toolchain first (I think) Mar 07 14:51:02 If I can get something to run on my spitz that would be great but it is my understanding that is currently being phased out (I certainly hope it will be phased back in) Mar 07 14:51:07 lool, hmm do you think qemu-img makes any difference in blocksizes based on imagesize ? Mar 07 14:51:34 Get 415 :...... Mar 07 14:51:42 how many pkgs to download Mar 07 14:51:47 ogra_cmpc: qemu-img no, but mkfs.ext[234] change block size depending on the image size Mar 07 14:51:57 lool, oooh ! Mar 07 14:52:04 * ogra_cmpc never thought of that Mar 07 14:52:21 Laibsch: Probably the script which I'm working on would give you the proper local setup for qemu syscall emulation Mar 07 14:52:21 aaron_liu, it should have told you somewhere up in the lig Mar 07 14:52:26 *log Mar 07 14:52:57 Laibsch, persia: http://paste.ubuntu.com/390390/ qemu-debootstrap take 2; finishes a bootstrap here Mar 07 14:52:58 lool: I assume I'd want to do that if my target device did not have the stack protector. I don't know, really. I just know the device I have. The good thing in OE is that there are machine configurations where still information is listed centrally. Would something like this be possible for ubuntu-arm? Mar 07 14:53:12 Laibsch: stack-protector is a toolchain feature, not a hardware one Mar 07 14:53:21 my head is spinning Mar 07 14:53:30 OE was good at hiding that kind of complexity Mar 07 14:53:35 I never had to bother Mar 07 14:53:49 Laibsch: I guess it would make sense to have a db of machine <-> features somewhere, but usually we expect hackers doing archive rebuilds for a target device to know it by heart anyway Mar 07 14:54:04 Laibsch: So e.g. if you're targetting a N810, you should know it's v6 + vfp Mar 07 14:54:12 I wouldn't ;-) Mar 07 14:54:33 Laibsch: I think you're correct that it's going to become an improper assumption Mar 07 14:54:38 Laibsch: We should aim at hiding this away Mar 07 14:54:40 over time, yes Mar 07 14:54:57 lig Mar 07 14:54:58 Laibsch: Do you have fast connectivity? Mar 07 14:55:03 eventually it would be good to "dumb it down" so that even stupid people like me can use it ;-) Mar 07 14:55:03 ? Mar 07 14:55:07 lig? Mar 07 14:55:12 *log Mar 07 14:55:20 lig! Mar 07 14:56:30 lool: depends on your definition of fast. When I am in Asia, I usually have 100MBit, but then it's more a problem of latency (really annoying). Over here, I have a few MBit down. Not really that fast by today's standards. Why? Mar 07 14:57:09 Laibsch, stay in asia then ... germany is to cold anyway :) Mar 07 14:57:09 Laibsch: if you want to create an armel chroot as discussed on the link you mentionned earlier, that's relevant Mar 07 14:57:27 Ok; script appears to work; now need to finish the biarch stuff Mar 07 14:57:29 who knows the irc channal of chromium-browser-arm Mar 07 14:57:59 ogra_cmpc: Asia is not as cold when you look on the thermometer, but inside the poorly insulated houses it's freezing. Summer and winter are more agreeable in Europe, me thinks, and thus spend them here. Mar 07 14:58:06 Laibsch, if you create chroots/images more often, use an apt proxy Mar 07 14:58:15 * Laibsch already does Mar 07 14:58:37 right, then lool's question is not as important :) Mar 07 14:58:43 OK Mar 07 14:58:53 He still has to fetch them a first time! Mar 07 14:59:00 i'am in asia Mar 07 14:59:00 right Mar 07 14:59:03 I'm patient ;-) Mar 07 14:59:13 so cool in this days Mar 07 14:59:28 faster is of course better. but my connection here is not that slow as to be unusable. Mar 07 14:59:40 so cool in this days in asia area Mar 07 15:00:13 aaron_liu: let me try to cheer you up. We frequently had -20° this winter Mar 07 15:00:25 and just yesterday we had 25 cm of fresh snow Mar 07 15:00:39 haa Mar 07 15:00:53 chree up Mar 07 15:01:02 cheers Mar 07 15:01:23 where r u Mar 07 15:01:29 lool: I also have access to a build host in a data center. that machine has 100MBit as well. and is much faster CPU as well. Mar 07 15:01:42 aaron_liu: pretty much right in the middle of .de Mar 07 15:02:26 wecome to shanghai china Mar 07 15:03:08 i never go aboard , no chance Mar 07 15:03:16 haa Mar 07 15:03:27 Laibsch, where do you sit atm ? Mar 07 15:03:35 <-- Kassel Mar 07 15:03:37 on a chair ;-) Mar 07 15:03:45 haha Mar 07 15:03:49 ogra_cmpc: a little further west Mar 07 15:03:53 it's night this time in the shanghai Mar 07 15:03:54 about an hour's drive Mar 07 15:04:07 ah, like solingen etc Mar 07 15:04:19 Sauerland Mar 07 15:04:23 yup Mar 07 15:04:51 lool: log "W:" "$0 is deprecated, please use qemu-debootstrap" Mar 07 15:05:00 should I rather use qemu-debootstrap? Mar 07 15:05:02 what's time in ur location Mar 07 15:05:11 4pm Mar 07 15:05:18 here is 23:05 Mar 07 15:05:45 Laibsch, its just a warning Mar 07 15:05:49 yes Mar 07 15:05:58 ogra_cmpc but where r u Mar 07 15:06:02 but while I'm starting I may as well use the latest tools Mar 07 15:06:11 but the plan is to make build-arm-chroot arch independent Mar 07 15:06:34 de have many time zone ? Mar 07 15:06:34 which means it will be renamed to qemu-debootstrap Mar 07 15:06:46 aaron_liu, nope, just one Mar 07 15:06:58 Laibsch: Not sure what you mean Mar 07 15:07:18 Laibsch: It's only when the script is symlinked as build-arm-chroot that the deprecation warning will be printed Mar 07 15:07:38 or if you saved it as build-arm-chroot :) Mar 07 15:08:04 yes, but I was wondering if qemu-debootstrap was preferred over that script Mar 07 15:08:13 Laibsch: That script is qemu-debootstrap Mar 07 15:08:20 hehe Mar 07 15:08:55 maybe s/use/rename\ this\ script\ to/ ? Mar 07 15:09:15 it will be in a package in the end Mar 07 15:09:20 ok Mar 07 15:09:23 users shouldnt rename package content Mar 07 15:10:17 the old name was build-arm-chroot ... the proof of concept stuff i created in karmic is now being generalized by lool to be less hackish and arch independent Mar 07 15:10:56 canada have a place with the name Hope same with urs Mar 07 15:11:04 * ogra_cmpc likes to do a lot of hardcoding ... lool prefers stuff to have tons of switches Mar 07 15:11:53 my hardcoding isnt so good for generalizing usually :) Mar 07 15:12:21 ogra_cmpc: Actually I hate switched too, but I hate hardcoding more than switches Mar 07 15:12:25 *switches Mar 07 15:12:32 heh, yeah Mar 07 15:13:01 hardcoding is good for quick shots and proof of concept stuff though Mar 07 15:14:06 will there currently be any tangible benefits for me if I use lool's script instead of ogra's scipt (which I understand is packaged in the repo) to compile for arm? Mar 07 15:14:23 Laibsch: Probably no difference for armel, no Mar 07 15:14:27 Laibsch: but it would help me testing it Mar 07 15:14:32 OK Mar 07 15:14:33 just that you need to learn the new name soon :) Mar 07 15:14:38 I will gladly do that Mar 07 15:15:11 I take that as you soliciting feedback Mar 07 15:15:28 You got yourself the dumbest person on the planet to do your testing Mar 07 15:15:38 I guess that may be a good thing in this case ;-) Mar 07 15:15:58 my hardware board will come tomorrow, i will debug the board ,hope without a hitch Mar 07 15:17:29 in the chat room ,who have debug the ddr2 board ,and give me some suggestion Mar 07 15:17:49 lool: http://paste.debian.net/62940/ I did take a look at the script (which I guess won't happen so frequently once it's packaged) but it's really unclear to me how to use it. Mar 07 15:18:01 I guess I may need to set deb_arch or arch or both Mar 07 15:18:06 Or maybe something more Mar 07 15:18:55 Ok this is what I intend to upload http://paste.ubuntu.com/390405/ Mar 07 15:18:57 sudo qemu-sebootstrap --arch armel Mar 07 15:18:59 has basic bi-arch support Mar 07 15:19:22 Laibsch, the debootstrap docs should apply Mar 07 15:19:38 Laibsch: The new version would work in your case, but it would create a chroot of the same arch as yours Mar 07 15:19:47 Laibsch: You need to tell it "armel" at some point Mar 07 15:19:52 OK Mar 07 15:20:01 Will you be uploading this script now? Mar 07 15:20:16 I'd prefer that over manually copying your latest changes every time Mar 07 15:20:35 Laibsch: I will be uploading it now, but it will need to build on your arch before you get it from the archive, will take some hours Mar 07 15:20:49 no problem Mar 07 15:21:00 what's the name of the package? Mar 07 15:21:42 lool, looks good to me Mar 07 15:22:24 Laibsch, qemu-arm-static or qemu-kvm-extras-static Mar 07 15:22:44 Oh, so it's an update to the currently available packages? Mar 07 15:22:49 that's even better Mar 07 15:22:50 * ogra_cmpc cant get used to the new name Mar 07 15:22:54 I already have those installed Mar 07 15:23:06 I agree Mar 07 15:23:26 but it's not only arm anymore, right? Mar 07 15:23:37 then it makes sense Mar 07 15:23:56 Did anybody ever use those scripts with pbuilder? Mar 07 15:23:58 i'm specifically unhappy about having kvm in the packagename Mar 07 15:24:02 Laibsch: Exactly, it would work for e.g. ppc Mar 07 15:24:05 * lool should test ppc Mar 07 15:24:25 Laibsch, persia works on the pbuilder stuff based on this Mar 07 15:24:32 cool!!!! Mar 07 15:24:35 extracool Mar 07 15:24:40 can't wait Mar 07 15:25:45 i must go to sleep or i would be late for tomorrow working Mar 07 15:26:00 good night! Mar 07 15:26:13 and good luck with your chromium hacking Mar 07 15:26:20 I should have tested native builds before uploading; bah Mar 07 15:27:07 good Morning Mar 07 15:27:14 bye Mar 07 15:27:19 Can I get debootstrap to use an apt-cache? I looked at the man page but I only see the option to specify a mirror. Or will debootstrap use the same settings as for the host? Mar 07 15:27:38 Laibsch: http_proxy is picked up by default unless you filter it Mar 07 15:27:41 Laibsch, just yse mirror Mar 07 15:27:46 Laibsch: a mirror can be specified on the cmdline Mar 07 15:27:47 *use Mar 07 15:27:50 third argument Mar 07 15:27:54 OK Mar 07 15:28:03 but it's really not an http_proxy Mar 07 15:28:08 nor is it a mirror Mar 07 15:28:13 Laibsch: what is it? Mar 07 15:28:14 Even though both should work Mar 07 15:28:16 a pool of .debs? Mar 07 15:28:24 I use apt-cacher-ng Mar 07 15:28:31 both approaches should work Mar 07 15:28:32 Laibsch: It's a proxy then Mar 07 15:28:45 (at least I think it is, I don't actually use apt-cacher-ng) Mar 07 15:28:50 sudo qemu-debootstrap --arch armel lucid lucid-chroot http://192.168.2.87:9999/ubuntu-ports Mar 07 15:28:56 Laibsch, ^^^ thats what i use here Mar 07 15:29:16 yes, as I said, both approaches will work Mar 07 15:29:18 the ip is my wlan0 on my laptop Mar 07 15:29:24 But Mar 07 15:29:42 I want an unaltered sources.list Mar 07 15:30:04 Laibsch: fix it after the build Mar 07 15:30:04 debootstrap doesnt create a sources.list Mar 07 15:30:06 And apt-cacher-ng is not an http proxy in the strict sense Mar 07 15:30:22 ogra_cmpc: Hmm I think it does now Mar 07 15:30:24 err ... it does Mar 07 15:30:30 yeah Mar 07 15:31:27 http://paste.debian.net/62945/ is my /etc/apt/apt.conf.d/proxy Mar 07 15:31:47 I'd like to have that the same in the debootstrap Mar 07 15:31:55 but it's not a big deal Mar 07 15:32:15 just cp it after creating the chroot :) Mar 07 15:32:28 Laibsch: It does act as a proxy; it's configured as your APT http proxy; anyway, apparently anything works, so don't worry Mar 07 15:32:59 thanks, guys Mar 07 15:33:45 i come back Mar 07 15:33:57 root@aaron-ubuntu:/# du -s /tmp/tmp.Vbz1uwY5yt/ Mar 07 15:34:05 still 1138632 /tmp/tmp.Vbz1uwY5yt/ Mar 07 15:34:32 did rootstock finish already ? Mar 07 15:35:02 but building database of manual pages Mar 07 15:35:35 just setting up.......... Mar 07 15:35:35 yeah, give it time, it takes long ... since it runs in a virtual machine Mar 07 15:36:59 ok, i go to sleep again Mar 07 15:37:03 bye Mar 07 15:37:14 it only emulates a 200MHz ARM dont espect it to be fast :) Mar 07 15:37:20 bah Mar 07 15:39:57 ogra_cmpc: what's the non-masked URL to ubuntu-ports? Mar 07 15:40:12 I see Mar 07 15:40:15 ports.ubuntu.com Mar 07 15:40:38 ports.ubuntu.com/ubuntu-ports Mar 07 15:41:03 (non ports use /ubuntu) Mar 07 15:45:51 which leads to the question of "what is a port"? Mar 07 15:46:12 Laibsch: It's just an arbitrary separation to not pollute the main arcihve/publisher Mar 07 15:46:20 ok Mar 07 15:46:24 makes sense Mar 07 15:46:48 everything except i386 is technically a port, even amd64, but we usually refer to ports as in the arches which are on ports.u.c Mar 07 15:48:00 apparently, qemu-ppc is much slower than qemu-arm Mar 07 15:48:41 lool, i talked to vargrant about it, he said ppc only works on a daily base with a lot of luck Mar 07 15:48:49 in debian at least Mar 07 15:49:05 I'm just speaking of the emulation Mar 07 15:49:17 The chroot creation is taking much longer in the configuring packages state Mar 07 15:49:38 well, you are lucky if it finishes at all is what i mean Mar 07 15:49:44 It just finished Mar 07 15:49:49 great ! Mar 07 15:49:57 he wasnt that confident Mar 07 15:49:57 root@bee:/# dpkg --print-architecture Mar 07 15:49:57 powerpc Mar 07 15:50:05 root@bee:/# lsb_release -cs Mar 07 15:50:06 lucid Mar 07 15:50:15 stuff works Mar 07 15:50:25 now I can trash it I guess Mar 07 15:50:35 i'll tell him to throw away these debian packages and use ubuntus instead :P Mar 07 15:52:16 lool: I have installed the lucid qemu-kvm-extras-static package. To help test your script, there's basically nothing left to do then the usual update routine and continue to run the build-arm-chroot script, right? Mar 07 15:52:34 right Mar 07 15:52:44 at some point it will tell you its deprecated Mar 07 15:52:59 then swiatch to qemu-debootstrap Mar 07 15:53:02 good Mar 07 15:53:48 I guess I can do that now ;-) Mar 07 15:54:28 qemu-debootstrap does not have a way to configure it with a dotfile, does it? I loathe those long command-lines, too easy to mess up Mar 07 15:54:49 i dont think so ... Mar 07 15:55:24 patchews accepted i guess :) Mar 07 15:55:51 Laibsch: You can use an alias or a wrapper if you don't want to remember the flags; pretty much everything is a variable though: arch, target, distro Mar 07 15:56:14 I should probably do that Mar 07 15:56:18 Laibsch: I don't like dotfiles for "pure" tools Mar 07 15:56:49 e.g. you don't have a dotfile for cp or expr, they just take their input and produce expected results Mar 07 15:56:49 hm Mar 07 15:57:15 you usually dont use a ton of options for cp or expr Mar 07 15:57:25 if you add a dotfile, you add a point where it might break, a compatibility interface to maintain, another thing to document etc. Mar 07 15:57:40 I have another thought Mar 07 15:57:41 * lool doesn't use a ton of options for debootstrap, I type the cmdline entirely every time Mar 07 15:58:16 * ogra_cmpc too, but i can understand if people find it hard and would like a config file instead Mar 07 15:58:59 Laibsch: You can have a higher level tool such as pbuilder pass the right args for you though Mar 07 15:59:18 OK Mar 07 15:59:21 that would work Mar 07 15:59:29 let's see when the pbuilder stuff arrives Mar 07 15:59:53 You dont actually need any pbuilder stuff Mar 07 16:00:08 But there's a wrapper which will help pass the proper pbuilder opts Mar 07 16:00:31 I was thinking that postinst of the package may create a bunch of hardlinks named build-$arch-chroot Mar 07 16:00:45 Laibsch: Would pollute the namespace a lot Mar 07 16:01:20 that's the intention ;-) Mar 07 16:01:22 I could argue we need a build-karmic-chroot and a build-lucid-chroot command too, and there would be no end of combinations ;-) Mar 07 16:01:31 I'm sure ogra_cmp would like it ;-) Mar 07 16:01:52 yes, I just find the releases easier to remember Mar 07 16:02:15 but as soon as you have a matrix of combinations you're better of with a config file :-P Mar 07 16:02:28 better off Mar 07 16:02:47 OK, next try Mar 07 16:02:52 how about bash-completion? Mar 07 16:03:14 Laibsch: feel free; bash-completion for debootstrap and qemu-debootstrap would be nice Mar 07 16:03:17 if the package shipped some information for bash-completion, I'd be happy and shut up Mar 07 16:03:21 OK Mar 07 16:03:24 Laibsch: These are really low-level tools IMO Mar 07 16:03:30 I've never actually made a patch for that Mar 07 16:03:41 Laibsch: I'd rather encourage you to fix this when you have a higher level "build image for board foo" tool Mar 07 16:03:42 Laibsch, you are right, i would like it ... Mar 07 16:03:42 but should be reasonably easy to do Mar 07 16:03:58 Laibsch: I personally use zsh BTW :-) Mar 07 16:04:12 but i argued with lool to often about it already :) he does the work so he may do the dedcisions :) Mar 07 16:04:12 you won't profit, then Mar 07 16:04:14 SOL Mar 07 16:04:44 lool: I agree and I'll wait for the higher level tools Mar 07 16:04:58 I never really call debootstrap on the command line Mar 07 16:05:10 If I do, I would not mind looking at the manpage Mar 07 16:05:21 when I do Mar 07 16:05:53 but stuff I call very often (and I thought I was going to need to call this script very often) I want to be easy to use Mar 07 16:06:34 lool: when do you expect the "build image for board foo" tool? Mar 07 16:07:01 Laibsch, rootstock will grow it for lucid+1 Mar 07 16:07:10 thats already planned Mar 07 16:07:15 ok Mar 07 16:07:34 when should we see prereleases? Mar 07 16:07:54 rootstock is already available Mar 07 16:08:12 what's rootstock anyway? Mar 07 16:08:13 just misses the plugin system that will enable per-board profiles Mar 07 16:08:22 a rootfs builder Mar 07 16:09:45 it would be the tool you would use if you wanted to build a full rootfs thats completely configured ... so you just untar it to an arm device that has bootloader and kernel and are ready to go Mar 07 16:12:51 Laibsch, see the rootfs from scratch wikipage from the topic for more info Mar 07 16:17:59 (i think also its the tool we have the biggest community participation for atm, i'm pondering to make its improvement a summer of code project for an intrested student) Mar 07 16:18:18 lool, what would you think about that ? Mar 07 16:19:09 I have three ideas which relate, but which don't really go in the rootstock direction Mar 07 16:19:32 thats sad since its adopted by so many people alredy Mar 07 16:19:46 why not just improve it Mar 07 16:20:00 I personally think it would be worthwhile to enable armel in vm-builder; vm-builder is widely adopted and will be maintained by the server team; vm-builder is extensible and I'm sure we could come up with per-board plugins Mar 07 16:20:24 i still dont see vm-builder as the right tool Mar 07 16:20:33 I also believe we need to think longer term and invest in a tool to build images after the debootstrap part, I have some ideas about that but it's too early to mention them here Mar 07 16:20:38 but i guess we'll disagree on that part forever Mar 07 16:20:59 and the third bit is that I think we should couple the second tool with a hosted workflow allowing to request image builds remotely Mar 07 16:21:20 right Mar 07 16:23:36 lool, but i'd like us to coordinate the efforts before we drift away in different directions here Mar 07 16:25:40 ogra_cmpc: I think vm-builder is a nice immediate consolidation point Mar 07 16:26:13 i dont think so ... my first criticism point wont ever be solved Mar 07 16:26:22 its not shell Mar 07 16:26:56 It wont be solved no, I'm not sure it's a drawback though Mar 07 16:26:59 rootstock gets so much particiaption from the outside because even a beginner can understand the code and commit a fix very easily Mar 07 16:27:03 It allows offering a python API for instance Mar 07 16:27:12 sure Mar 07 16:27:28 i agree that its definately better for gui integration etc Mar 07 16:27:44 Let's agree to disagree Mar 07 16:27:52 yeah :) Mar 07 16:35:56 sigh so the '-T small' option for mkfs.ext3 doesnt fix the hang Mar 07 16:38:14 * ogra_cmpc tries to just set the blocksize Mar 07 16:41:46 lool, whats the biggest image you have used yet with lucid qemu ? Mar 07 16:41:59 in armel emulation indeed Mar 07 17:15:07 lool: http://paste.debian.net/62953/ qemu-bootstrap fails Mar 07 19:30:32 ogra_cmpc: Sorry, I'm not sure Mar 07 19:31:11 Laibsch: That's interesting; could you run that command? Mar 07 19:31:25 Laibsch: chroot lucid-armel-chroot dpkg --force-depends --install /var/cache/apt/archives/base-files_5.0.0ubuntu10_armel.deb /var/cache/apt/archives/base-passwd_3.5.22_armel.deb Mar 07 19:31:37 or s#dpkg#/usr/bin/dpkg# Mar 07 19:33:52 lool: http://paste.debian.net/62992/ dependency problem? Mar 07 19:35:13 there is no awk package in /var/cache/apt/archives/ Mar 07 19:36:54 same for gawk Mar 07 19:49:36 Laibsch: Could you run chroot lucid-armel-chroot /debootstrap/debootstrap --debug --second-stage ? Mar 07 19:50:01 Laibsch: mawk should have been unpacked by debootstrap Mar 07 19:50:08 (not by dpkg though) Mar 07 19:50:17 oh that's just a warning Mar 07 19:50:23 Laibsch: Your problem is dpkg: ../../src/archives.c:754: tarobject: Assertion `r == stab.st_size' failed. Mar 07 19:50:28 Laibsch: That's the same bug I reported Mar 07 19:50:36 Laibsch: Just create the chroot outside of home directory Mar 07 19:50:45 Laibsch: It's an ecryptfs bug exposed by recent changes to dpkg Mar 07 19:50:57 I see Mar 07 19:51:14 bug #524919 Mar 07 19:51:15 Launchpad bug 524919 in linux (Ubuntu Lucid) (and 4 other projects) "ecryptfs breaks lstat/readlink size assumption (affects: 1)" [High,Confirmed] https://launchpad.net/bugs/524919 Mar 07 19:51:50 I'm restarting in /usr/src Mar 07 20:13:20 that was successful Mar 07 20:13:22 great! Mar 08 00:21:28 lool: Needs work on options to handle both --arch powerpc and --arch=powerpc, but looks lovely otherwise. Mar 08 00:29:49 Ugh. No it doesn't. Looks bug-for-bug compatible with debootstrap :( Mar 08 00:30:28 Anyway, you shipped it, and it looks good, and I'll make the tools use it. Mar 08 00:31:51 ( well, unless system_arch == amd64 && deb_arch == i386 | lpia ) Mar 08 01:43:38 morning all Mar 08 01:46:48 i'm coming again **** ENDING LOGGING AT Mon Mar 08 02:59:57 2010